16 ms·

Code is run more than read

811 points by signa11 3y ago

bruce511 3y ago
Very nicely explained, as I kept reading it covered all my experiential "yes, but" thoughts. I will add that-knowing- all this is helpful, but implementing it when you are early in your career is hard. For example, it's good that Business is the big priority, but when you gave no experience of what is good, or bad, in business, it can be hard to understand the ramifications of decisions made now. Equally, business priorities should win, but your goals and the business goals may not be aligned. An individual may need to resume-pad (learn that new framework) while the business may want homogeneity (everything built on one framework.) Finally, of course, this refers to commercial software. Open Source software is the exact opposite flow, dev > maintainer > user > business. Which ultimately explains why it's so hard to get funding for OSS.
- 082349872349872 3y ago
  Then again, the original ideal for OSS is that (just like owning a home is having the tenant and the landlord be the same person) devs and users are the same, so: (dev = ops = user) ≹ (biz).
- goodpoint 3y ago
  > Open Source software is the exact opposite flow, dev > maintainer > user > business That's a pretty sad assumption. "dev > user" is why a lot of projects have very poor usability.
  - bruce511 3y ago
    Obviously it's not true for all projects. But it's true for most of them, no?
  - zen928 3y ago
    devs have to use it to hoist it to a platform that can accessed by others before users can use it, right? imo users don't typically use open source software, they use generated artifacts from an upstream development process representing the capabilities of the software. users don't "use grafana", they use the implementation of how you deploy it. it should be improved upon by responses from the users who use your implementation, but what you're saying suggests that efforts like architecting your software in ways that improve/maintain development standards or packaging your software in a dependency manager before delivering any level of user facing feature is a sad assumption to you. I don't think the concern of usability here takes the entire picture of a project into context.
devjab 3y ago
I don’t think I agree with the sentiment that user doesn’t equal business, to some degree maybe, but a business is what its users produce. I buy the point that some users within a business can have a demand for processes that will not be good for the business because they may be too focused on their specific department, but as a whole I think they are largely the same thing. Happy users work better, better work is good for the business. Aside from that, I think a lot of the “bad” decisions are unavoidable as businesses grow, so too with the bureaucratic demands that are often not producing value, but it’ll be very hard for the “IT department” to do anything about it because it lives as a “service” department similar to HR, but less understood by management. Cost-centres never get political power to match money makers. I do think it’s a very interesting article, perhaps with a bit of a baiting headline. But I think it would be even better if it included the perspective of the modern ci/cd pipeline. What I mean by that is how we’re building more and more automation into it, things like RennovateBot that will automate certain parts of your maintenance processes. Things that won’t work automatically if you don’t write clean testable code. If you focus on delivering business value, spaghetti be damned, you’re going to end up spending so much time maintaining it that you’re eventually not going to be capable doing what you set out to do. We used to live on a world where this was sometimes ok, because you’d clean it up once the value was created, but with how much you can gain from a highly automated pipeline, I just don’t think that paradigm is true anymore. Because not only will you have to clean things up, you’re also going to miss out on so much efficiency by not being capable of using these automated tools. You can make the argument that you don’t need to update things as often as those tools help you so, and 5 years ago you would have been correct. Many places you may even still be correct, but in large organisations in the EU this is just no longer the case because of the added legislative bureaucracy that IT security needs to play into.
antoineMoPa 3y ago
I'm not sure I agree with everything, but I love the mental models this introduces.
drewcoo 3y ago
It is not about the comparative values of humans. It is about costs. The reason we write readable code is because we spend more time reading it than writing it. Engineer time. Which is money. Yes, other things are money considerations, too. Considerations the advice to write readable code is not meant to address.
quickthrower2 3y ago
I was sceptical but you know what, I love this mental model. Don’t follow it blindly of course, there are exceptions where dev > biz (see OpenAI debacle) and where dev > ops (early stage startup, move fast, in particular dev > ops because biz)
smt88 3y ago
For many of us, running our code 1 billion times will cost less than a few minutes of a developer's time. Hell, I could spend $200 for a month of server time on AWS and run a lot of my (web API) code 100 billion times. Optimizing for human readers is always better until you're working on something that proves itself to be too slow to be economical anymore.
- krab 3y ago
  In my experience, you need to care about latency. That affects user experience. It's quite hard to pay for better latency.
  - groestl 3y ago
    You do that by paying for better developers ;)
  - rezonant 3y ago
    That depends on the application and the use case, but good performance and good readability aren't mutually exclusive. Easy to read software might not always be the most performant, but it's far easier to improve performance in an easy to read codebase than it is to make a hard to read but performant codebase easier to read.
    - krab 3y ago
      Yeah, that's right. I just feel that latency is sometimes missing from the discussions re. developer efficiency vs paying more for compute.
      - josephg 3y ago
        Yep. Theres a huge experiential difference between something happening instantly and it happening in 200ms or so. Especially when typing or playing video games.
        3y ago
danielovichdk 3y ago
That's not the point. The point is that a computer is not involved in the creative and qualitative process, it does not care. Humans are different ad you might all know. So of course code should be readable over being runnable.
- murkt 3y ago
  You haven’t read the article past the headline, have you? It’s not about computers running code, it’s all about humans.
  - danielovichdk 3y ago
    "It doesn’t matter how well written or maintainable the code is, nor how sophisticated the technology it uses if it doesn’t fulfill its purpose and provides a good experience to the user" This is what I was commenting on. And I do not agree with it because it underlines the dogma about how little craft quality means as long as someone finds it useful. You could also hammer 3 wooden boards together and call it a chair. But that's not for me, it's simply too shallow a mindset for being a professional software engineer.
    - johnnyanmac 3y ago
      >I do not agree with it because it underlines the dogma about how little craft quality means as long as someone finds it useful. YMMV vastly based on industry (or in the lens of this post, the demands and requirements on the user end to satisfy). For media, it's fine; very few users are going to suffer over a few minor bugs or an unoptimal system. For aerospace, it's fatal thinking for obvious reasons (with sadly, many real world examples to point to). Both are valid career aspects and both provide value. >it's simply too shallow a mindset for being a professional software engineer. sounds like you fall under "the right thing", as the author calls it. A sadly dying aspect as elephants and late stage capitalism (again, as the author named them) run wild. But I argue more that this is just fine for an engineer. You're thinking more like a professional computer scientist. scientists observe and model the nature around them. Engineers apply them, while taking into account the imperfections of nature and yes, humans. In my eyes, an engineer that can't adjust to the needs of the product (be it for biz, users, or someone that is not them) isn't an engineer, but a scientist. Or a craftman, as you deferred to ealier. Again, not a slight nor compliment, just different roles with different philosophies.
_nalply 3y ago
Because we as programmers need to know how to progam: learning trumps all. Thus: learning > biz > user > ops > maintainer > author There was that bit dev > * meaning resume-driven development, but in reality it is learning > * And that's the conflict programmers experience in corporate structures, for example the hassle programmers experience when they interview for a position. Employers know it too but they try to shirk it.
- ahoka 3y ago
  My gripe with most programmers that they keep re-learning the same narrow set of skills while ignore the rest that actually makes someone a efficient expert.
  - f1shy 3y ago
    I could expand that though to a much larger set than programmers!
  - sirsau 3y ago
    What do you think programmers ignore that would be beneficial?
    - codebolt 3y ago
      Their working domain. If you're a developer in financial services, learn finance. If you're a developer in oil exploration, learn seismology. Don't constrict yourself to only being a programmer who writes whatever code you're told to. Be a holistic problem solver.
      - rexpop 3y ago
        What's in it for me?
        rob74 3y ago
        Maybe not needing to rewrite your code several times after being told that it's not what the client wanted to have?
solatic 3y ago
> And while we can’t just go back to ignoring the economic realities of our discipline, perhaps we should take a stronger ethical stand not to harm users. Acknowledging that the user may not always come before the business, but that the business shouldn’t unconditionally come first, either. This is why software engineering needs licensure. Not to check if people understand design patterns, or whether people know the fad library of the day, but to set clear ethical standards and hold people to those standards by disbarring them if they violate those standards. Or more to the point: society > biz > user > ops > dev
- ametrau 3y ago
  That’s really interesting. Barbers need a license (in Australia), lawyers need one, and yet people writing potentially crucial software do not.
  - defrost 3y ago
    There's no shortage of hairdressing "institutes" in Australia promoting certificates awarded after passing their training courses and no doubt existing shops would look to see some evidence of skill before hiring .. however: Licensing/registration of hairdressers, beauty therapists and barbers is currently not required, legally binding or a symbol of any kind of standard in our industry. In previous times, there was a hairdresser’s trade license which was abandoned, without consultation with the industry. Re-establishing such a license would need to be done in conjunction with governments and education partners like TAFE’s and Private Colleges to ensure that the necessary awareness and legal processes are followed. Simply announcing that you are creating a license/registration for employees, and charging on the spot, simply won’t cut it. Hair & Beauty Australia Industry (2017): HAIRDRESSER LICENSE NOT NECESSARY AND NOT LEGAL https://www.askhaba.com.au/hairdresser-license-not-necessary-not-legal/ https://www.askhaba.com.au/hairdresser-license-not-necessary...
- krzychukula 3y ago
  IMHO. The article makes a wrong call to action. It calls for dev ethics when the problem is biz ethics. Instead of licensure wouldn’t it make more sense to have more rules and oversight for the companies?
gostsamo 3y ago
So, the author hijacks a perfectly good rule of thumb to build their grand theory of everything. It is all nice, clean, and wise, and besides the tortured turn of phrase is just rechewing of popular truisms.
- rob74 3y ago
  To say it more precisely, their grand theory of everything that can go wrong in software development. But interesting read nevertheless...
- m463 3y ago
  so: theory > /dev/null
  - Planktonne 3y ago
    Beautiful.
  - collyw 3y ago
    pragmatism > theory
  - sltkr 3y ago
    blog < /dev/random
- thomastjeffery 3y ago
  Did you read to the end? Everything else is backstory.
- gotski 3y ago
  Honestly, I think there's value both in riffing off rules of thumb and using that riff to revisit and re-contextualise things we already think we know. Everything is new to someone, and even if this was just confirming my own biases I found it an interesting take.
- deleted 3y ago
  [deleted]
ekaramese 3y ago
It is filled with wisdom. I can not imagine the most genius programmers try to sell lingerie to people in google, facebook etc. purpose > *
YoshiRulz 3y ago
> There’s a lot of software being produced that just doesn’t care about its users [... caused by] a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable [... so] perhaps we should take a stronger ethical stand not to harm users. Or, we could ditch the "biz" part. It just so happens that software not written to serve business interests tends to also respect users.
- vasco 3y ago
  If we ditch the business part what's your recommendation to pay rent?
  - cybrox 3y ago
    Just ditch the paying rent part.
  - layer8 3y ago
    It's possible to get paid for writing software that secretly doesn’t solely serve business interests but also and even primarily repects users.
  - YoshiRulz 3y ago
    I happen to believe in subsidised/affordable housing (I assume a UBI is what cybrox meant by not paying rent; also cracking down on housing-as-investments[1] sounds good to me, a layman, though apparently it wouldn't be enough[2] in our case, supply just needs to increase)—but I'm sure that other, less drastic societal changes would also be sufficient. For example, medium to large businesses could fund any open-source projects they make direct use of[3]. With the likes of OpenCollective[4][5] and GitHub Sponsors[6], the only roadblocks to adopting such a policy are corporate red tape and corporate greed. (And if it leads to smaller SBOMs, well, that's just a bonus as far as I'm concerned.) All that said, I was actually referring to individuals (who aren't necessarily developers) choosing which software to use. Over the last 20 years, we've all taken free downloads and sign-ups for granted, ignorant to that whole "if you're not paying, you're the product" thing, and a lot of us now have a $500+ supercomputer in our pockets which is to some extent owned by a tech giant and not its nominal owner. It's apparent that such centralised platforms have some intrinsic problems with regards to users' freedom. That's what I'm cautioning against—not the idea of selling your programming labour to a business, which is fine. [1]: https://en.wikipedia.org/wiki/Australian_property_bubble#Foreign_investment_in_residential_property https://en.wikipedia.org/wiki/Australian_property_bubble#For... (This article is outdated. From a quick web search, it seems foreign real estate investment fell during the pandemic but has now picked up again.) [2]: https://www.abc.net.au/news/2022-09-02/housing-property-australias-one-million-empty-homes/101396656 https://www.abc.net.au/news/2022-09-02/housing-property-aust... (1M unoccupied houses in a country of 26M, ~120k of whom don't have secure housing...) [3]: https://stackoverflow.blog/2021/01/07/open-source-has-a-funding-problem/#h2-e80da1e18ef10 https://stackoverflow.blog/2021/01/07/open-source-has-a-fund... [4]: https://blog.opencollective.com/funds-for-open-source/ https://blog.opencollective.com/funds-for-open-source/ [5]: https://docs.opencollective.com/help/financial-contributors/organizations/sustainer-resources https://docs.opencollective.com/help/financial-contributors/... [6]: https://docs.github.com/en/sponsors/sponsoring-open-source-contributors/sponsoring-an-open-source-contributor-through-github#sponsoring-accounts-in-bulk https://docs.github.com/en/sponsors/sponsoring-open-source-c...
gary_0 3y ago
"biz > user" is valid on paper because someone has to pay for the party; there are a finite number of software devs and capitalism is great at allocating scarce resources where they're most needed. Or at least the "spherical cows" version of free-market capitalism is great at that. In that version of capitalism, if your OS spends too much time putting spam in the Start Menu and not enough on fixing bugs, you can just switch to that other OS with full support from hardware vendors, that runs all your closed-source legacy software. If your favorite bird-themed social media site starts doing boneheaded stuff, you can just switch to that other site that has all your friends and data and lots of posts from experts and celebrities. If your search results are full of spam, you can switch to that other search engine with 10,000 highly paid engineers and 20 years of experience in Web search and integration with all your devices. And all the businesses you moved away from would have to clean up their act or go out of business. If only those cows were perfectly spherical.
- thegrimmest 3y ago
  Just because this doesn’t happen instantaneously doesn’t mean it’s a fantasy. Large changes in an ecosystem always take time. It may be years before the incumbents are truly displaced, but that doesn’t mean they won’t be. MySpace and RIM also seemed like they’d be there forever.
  - gary_0 3y ago
    "In the long run, we're all dead."
  - layer8 3y ago
    You'd have to explain your optimism of things eventually getting better, given that they've largely become worse over the past 10-15 years. Maybe it'll just be meandering around a mediocre-at-best mean level long-term.
bmitc 3y ago
> Software should have a purpose, it’s supposed to provide a service to some user. It doesn’t matter how well written or maintainable the code is, nor how sophisticated the technology it uses if it doesn’t fulfill its purpose and provides a good experience to the user: > user > maintainer > author This is completely wrong. To see why, replace the > signs with = and work backwards from there.
- falserum 3y ago
  Please elaborate.
BlackCherry 3y ago
This article codifies general power structures within organizations: who trumps who when making software decisions in an org and sells that status quo as some sort of useful rule of thumb, when it in fact has no utility at all.
kuldeepfouzdar 3y ago
Open source [not-for-profit] software says: Hello?
rob74 3y ago
TIL of ≹, which "articulates a relationship where neither of the two compared entities is greater or lesser than the other, yet they aren't necessarily equal either. This nuanced distinction is essential in areas where there are different ways to compare entities that aren't strictly numerical." (https://www.mathematics-monster.com/symbols/Neither-Greater-Than-nor-Less-Than.html https://www.mathematics-monster.com/symbols/Neither-Greater-...)
- namanyayg 3y ago
  Likewise, TIL. In your link however it states "Example 1: Numerical Context Let's consider two real numbers, a and b. If a is neither greater than nor less than b, but they aren't explicitly equal, the relationship is ≹" How can that be possible?
  - magicalhippo 3y ago
    Perhaps this: if they represent angles, then 1 and 361 represents the same absolute orientation, but they're not the same as 361 indicates you went one full revolution to get there. Contrived, but only thing I could think of.
  - thaumasiotes 3y ago
    It isn't. The real numbers are a totally ordered field. Any two real numbers are comparable to each other.
  - shaunregenbaum 3y ago
    I would imagine trying to compare a purely imaginary number (3i) to a real number (3) would suffice.
    - thaumasiotes 3y ago
      An imaginary number wouldn't obey the stated constraint of being real.
      - 3y ago
e____g 3y ago
Counterpoint: machine code may be run often, but source code is run never.
ofey404 3y ago
A good article with a misleading name...
- thomastjeffery 3y ago
  Then again, it doesn't mislead very far.
rexpop 3y ago
To avoid violating my egalitarian principles, I choose to read ">" as "depends on."
vinay_ys 3y ago
The author's framing can be misunderstood in so many ways that it is not a useful shorthand at all. There can be no absolute rank order of these tokens. Firstly, in this framing, the "dev" is not one person but it is a collective for lots of people with varied expertise and seniority levels in different orgs – product, engineering and design orgs. Then, "ops" is again not one thing and not just engineering ops. It could be bizops, customer support etc. too. Then, "biz" isn't one thing either. There's branding/marketing/sales/legal etc. and execteam/board/regulators/lenders/investors etc. All of these people affect what code is written and how it is written and how and when it is shipped to users. Everyone should be solving the same "problem". A lot of the times, a lot of people within the org are just there to make sure that everyone understands/sees the same "problem" and is working towards the same goals. But that understanding is continuously evolving. And there is lag in propagation of it throughout the org. And hence, there is lag in everyone working towards the same goal – while goal itself is being evolved. Finally, "user" is not one thing either nor any one cohort of users are static. There are many different cohorts of users and these cohorts don't necessarily have long-term stable behaviors. So, it helps to understand and acknowledge how all the variables are changing around you and make sense of the imperfect broken world around you with that context. Otherwise it is very easy to say everyone else sucks and everything is broken and you want to restart building everything from scratch and fall into that and other well-known pitfalls.
hamdouni 3y ago
biz > user This one sounds like there is only the HN reality of dev : startups, VC, growth hacking, free until is not, client=product, burn every $ to reach monopoly,... But, there is another one with small businesses, craftsmanship, get what you pay, client=client...
jeffparsons 3y ago
Hey, author, if you end up reading this thread: put the conclusion on a sticker. I'll put one on my laptop and give a bunch to friends. For anyone that didn't make it to the end, the conclusion was: user > ops > dev biz > ops > dev biz ≹ user
- karmakaze 3y ago
  In the long run user > biz, otherwise users will be using a product of a different biz via the enshittification cycle.
  - jeffparsons 3y ago
    Assuming a non-shit business, you could think of "biz" as "customers integrated over the long term". Therefore putting "users" and "biz" as incomparable could be interpreted as prioritising users, sustainably. At least that's how I interpret it.
  - layer8 3y ago
    There are enshittified monopolies and oligopolies, with lots of moats.
hasoleju 3y ago
This article has opened up a new perspective for me. It articulates very well that software is a means to an end. It's a craft that can be used to solve a problem. In my past I often emphasized the craft part too much. As if only writing perfect code is all you need to do in order to be successful. The really important stuff is understanding the problem you want to solve and being sure that software is the tool to solve this particular problem.
- cybrox 3y ago
  The person understanding the problem to solve and the person crafting the solution don't necessarily need to be the same person, though. They can, in fact, be two people with completely different skill sets and if one of them ("you") can "only" write perfectly beautiful code, they can still succeed by relying on the other for breaking down the particular problem.
azangru 3y ago
I think what I am seeing in this article is a curious mixture of should and does. For example, the "user > dev" formula is a clear example of "should"; but when he gets to "biz > user", he surreptitiously switches to "does". He explains the biz > user by pointing out stakeholders, and investors, and personal interests, and politics, and all other sorts of crap that, in the real world, puts biz before the user. Very understandable. But should it? And why isn't the same explanatory method applied to the "dev > *" formula? After all, there are clearly very strong personal interests involved in that too.
- C0mm0nS3ns3 3y ago
  > But should it? How would it work if it wouldn't? He explains what he means by that. If you spend time and resources on all things the users require and your run out of money and go out of business, everybody loses. Of course you can take any of the "rules" and take them to an extreme where they become wrong. But I think if you don't push them to their breaking point they are good rules of thumb :)
  - azangru 3y ago
    > How would it work if it wouldn't? He explains what he means by that. If you spend time and resources on all things the users require and your run out of money and go out of business, everybody loses. I think there is also a bit of a conflation of values vs ability. The formulas in the article represent values. Real life adds constraints based on what's possible. Consider his formula for dev vs user: "user > dev". You could argue that, just as a business is constrained by time and money, so is the developer constrained by time and skills. And yet, the author is happy with turning the greater than sign towards the user in this formula. Why?
    - deleted 3y ago
      [deleted]
    - filleduchaos 3y ago
      It's the same thing. If you bias your time and resources towards the things the dev require and/or would like and nobody actually wants to use the resultant software, you equally crash and burn and everyone loses. It's a priority ranking, not a zero-sum game.
kazinator 3y ago
Code being run more than read means this: code is read more by machine than by person. Users don't read code much, on the other hand. Thus: machine > maintainer > author > user QED
low_tech_punk 3y ago
I know this is considered wrong in so many ways, but my personal job satisfaction depends on dev > *, and in an ideal world, with open-source and end-user programming, we get user == dev > *
nehal3m 3y ago
I think the corollary to the title (to turn it around on the author) is not 'Code is read more than written' but 'code that can't be read won't run for long'. Disclaimer: Experienced sysadmin trying to make a lateral move to development and as such a complete noob.
- rafaelmn 3y ago
  > code that can't be read won't run for long There's plenty of ossified code people are scared to touch because they don't understand it, but stake their business on it :)
  - thfuran 3y ago
    And even executables for which the source code has been lost but which are still important to business operations.
  - Lutger 3y ago
    Or just code that works and nobody wants or needs to spend money on changing. I've written such code, very crappy stuff. And then coming back to the client many, many years later, finding it all just humming along, driving their business critical applications without it or the computer it runs on ever having been updated once in 5 years or so. I was so surprised, and a bit scared. Sometimes when you don't change anything, it just keeps working. So I guess that makes it a very boring: code that can't be read won't be changed and will not be relevant for long, but not always
  - couchand 3y ago
    One of my clients is convinced that a short hunk of JavaScript code that nobody can clearly describe the behavior of is their most valuable asset. Non-coders are weird.
  - LtWorf 3y ago
    I (very briefly) worked in a startup whose business was search (on a certain domain) and they had no tests for their "Search.java" file (the real name was 300x longer, because java devs…). I had found some operations to tweak the scoring, except that some were multiplications by one, so I removed them. But I got told to not touch them because they wouldn't know if I had broken it until some customer complained. The CTO told me off for my completely irresponsible behaviour.
j16sdiz 3y ago
> I can’t make a Google search without getting back a pile of garbage. I think SEO / Spammer share lots of that guilt. Not sure how to attribute them correctly.
- xiphias2 3y ago
  It's quite easy: Google giving better results than the minimum needed to make sure users don't switch is detrimental to its ads revenue. If you look at how many people are working on search at Google, it's just a small part at this point, vast amount of people at Google work on different ways of monetizing it.
deleted 3y ago
[deleted]
gloosx 3y ago
Quality article – for years of developing software, I have the bingo – heard and got used to every smell as long as there was air to breathe. I'm always in the end of this chain, doing the dirty work :)
atoav 3y ago
Also cars are driven more than repaired. Highways are used more than they need to be maintained. Yet if you don't include some thought to how to deal with a situation where something breaks, this could (and very likely: will) eventually come back to haunt you. But code is not the same as your car. If money is not an issue and your car breaks you could just get another one that drives equally well. Try doing that if your code breaks. So whether values like readability, maintainability etc. can be important for good code is out of the question — what remains an open question is (on a per file basis) how to priorize between those two if such a need arises. And that isn't a small "if": One should guard themselves against the simple thought that these are inevitable tradeoffs that are mutually exclusive. You can easily make code that is both unreadable and doesn't run well. You can also make extremely readable code that runs nearly perfectly. The latter is of course harder than writing the same code to just run well, but if you are not coding alone or your project is beyond a certain scale it might be well worth the extra thought. The solution space for "clear structure" and "good performance" is smaller than for either of those alone, so finding a good solution here is a bigger challenge, but depending on what you plan to do it could be worth a try.
rafaelmn 3y ago
You have to have something worth running first.
rtpg 3y ago
Kind of funny, but I have seen code that is indeed read more than is run, at least for the first year or two of its existence. Code that is used for generating batch reports for some billing process would run once a month. But I had to spend a lot of time staring at it, wondering what is going on, and fixing things up as reports came in. One could say that the test runs were run more than the code was read (of course), but in production? Definitely the same order of magnitude for a long time.
shenbomo 3y ago
[flagged]
deleted 3y ago
[deleted]
otikik 3y ago
I expected to be very defensive when reading the title but I actually fully agree with the article, thank you for sharing
deleted 3y ago
[deleted]
emrahcom 3y ago
Needed to define customers and users separately
t43562 3y ago
Some users are not using a system because they like it but because their company bought it. In those situations biz > user by definition and the developers end up having to cater to the needs of the middle managment of their customers rather than the needs of the actual users. The price of not doing this is failing to win the contract. Users then get locked in to whatever crap you have time to provide for them while you're really busy implementing new features that middle managment like. You essentially only need a nice looking login screen and some sort of reporting and the rest.....doesn't matter much. I am being a bit cynical but it does pay as an engineer to know if that's fundamentally the kind of company you're in. An online retailer, for example, is hypersensitive to its users and I know of at least one that has different versions of its website for different countries because they know that Germans like X and Americans like Y - small changes make a huge difference to sales. Other companies have no sensitivity to the usability of their products because the people who buy their products are never the users.
- derangedHorse 3y ago
  Typically middle management are users as well, but they are a minority of the user base and use a different set of features (like reporting). So now this becomes a question of which users are prioritized and finding a balance between prioritizing the experience of the small number of users who hold power over the rest, and keeping the product usable enough for the rest of the users to provide some value in data to management.
  - pixl97 3y ago
    Or as I've told the devs in the place I work "Don't fuck up the data path to the reports, it is a cardinal sin".
- bluGill 3y ago
  This is short term thinking - users who hate software can voice enough complaints to get things changed in at least some situations. (not all: many SAP programs with garbage UIs exist)
  - 3y ago
Alifatisk 3y ago
Code is run more than read. Code is read more than written. Code is written more than ...?
- tomovo 3y ago
  ...correct?
  - Alifatisk 3y ago
    "tested" feels more suitable
- collyw 3y ago
  tested
redhale 3y ago
I'm not sure I've ever read an article where so many times I thought "ok fine, but ..." only to have the next paragraph address that exact point each and every time. The ending point especially. As others here have pedantically pointed out (as HN is wont to do), there are ways to misinterpret or muddle some of the phrasing used here. But I think that's true of any reasonably simple (and therefore broadly useful) mental model. To me, this is a useful way of framing these ideas at a high level.
lhnz 3y ago
The article is good on the whole but the title "Code is run more than read" seems false in many situations I've been in. A lot of software doesn't have users. Often the target users don't like the product enough and are just trialing it for you as a favour. In these cases, it's not very meaningful to say it's being "run more than read", because either you should have made the code readable enough for other developers to delete it, modify it or rewrite it until users want to use it, or the code has to be valueless and able to be completely thrown away (the knowledge of how to build it is either written down elsewhere or tacit). I also agree with what somebody else said about the times in which the features/fixes you create aren't seen by users but just benefit a business-to-business sales process. In these cases, you behave differently. You do the work because there's a very clear signal to your company meeting their expectations promptly. I guess one way I would agree with the article is that once something has users/businesses and is somewhat readable you apply your extra effort on polishing the user experience as prioritising the happiness of your core users is generally a good idea.
amai 3y ago
I like the clean design of this blog. Is is very well readable on my smartphone.
xpe 3y ago
I'm glad to see something approaching ethics discussed: > There’s a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable, and I think that explains the increasing discomfort of many software professionals. "Discomfort" is quite the understatement. This leaves so much unsaid. I will add some questions: - What happens when your users are not your customers (the ones that pay)? - Does your business have any ethical obligation to your users -- all of them -- even the ones that do not pay? - What happens when your paying customers seek to use your business in ways that have negative downstream effects for your users? For example, what if: - Your platform makes fraud easier than the existing alternatives? - Your platform makes it easier to misinform people in comparison to the alternatives? - Your platform makes it easier to shape user opinions in ways that are attractive (habit-forming) but destructive in the long-term? All of these have proven to be successful business models, over some time scales! Given the reality of the dynamic, should a business pursue such an exploitative model? If so, can it do so more or less responsibly? Can a more ethical version of the business mitigate the worst tendencies of competitors? Or will it tend to become part of the problem? A key take-away is clear: some classes of problems are bigger and more important than the business model. There are classes of problems that can be framed as: what are the norms and rules we need _such that_ businesses operate in some realm of sensibility? Finally, I want to make this point crystal clear: a business inherently conveys a set of values: this is unavoidable. There is no escaping it. Even if a business merely takes the stance of 'popularity wins', that is in itself a choice that has deep implications on values. Political scientists and historians have known for years about the problems called 'tyranny of the majority'. Food for thought, no matter what your political philosophy. I don't know 'the best' set of ethics, but I know that some are better than others. And I hope/expect that we'll continue to refine our ethics rather than leave them unexamined. [Updates/edit complete as of 8:03 AM eastern time]
- ebiester 3y ago
  I believe this is a different problem than the essay is speaking about. You can choose what problems and domains fit your ethics. This is about how you build a system and how you prioritize the work.
WolfOliver 3y ago
Nice article, I always had the impression that we value DX a little too much. I mean developers are paid to do the jobs, but users are not.
bogrollben 3y ago
Nice article. I'd like to point out that a mature/legacy codebase contains every example listed under the "smell" section of the article, sometimes even within the same file. This creates a great deal of complexity to unwind beyond the mere coding of it all.
- nikanj 3y ago
  And an enterprising code keener will insist on rewriting that legacy codebase to eliminate all "smells", replacing battle-tested, bug-free-but-bad-smelling code with fresh, elegant, untested and nice code. Every generation relearns this the hard way, this blog post is 23 years old today and still 100% on the money https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
a_c 3y ago
I think the message is very profound. It is one of the message like "eat your veg, exercise, sleep well, love your family". On surface one would respond "yeah who doesn't get that". Who doesn't know software is as good as getting used? Oh wait, but no, what about knowledge, wealth, career, fame, status, entertainment and so many more. What about architecture, maintainability, scalability, trendiness, developer experience, team management, OKR, career prospect, and others? A punch is a punch. Software is about getting used. (I swapped user with used, IME user can mean different things to different people)
deleted 3y ago
[deleted]
HPsquared 3y ago
CPUs are lower in the hierarchy than developers.
timeon 3y ago
Just side note. Article is written in context of business. But sometimes there is non, like public sector. Nevertheless, article covered this context in the end as well.
asylteltine 3y ago
Rolled my eyes at the capitalism comment. Was that really necessary? Idealism > logic
Nevermark 3y ago
For enterprise software: Customer > User ??
bee_rider 3y ago
Businesses don’t really exist, they are an imaginary construct that we’ve come up with to help organize resources, ultimately in the interests of working together. Business isn’t more important than anything. There are multiple users, sometimes with competing interests; you can’t be everywhere and everything, so you have to prioritize. Going after more profitable users or users that align with some long-term strategy could be seen as “good for the business,” but really the goal is to serve the users (it might just take a couple extra steps). When the internal politics get confused to the point that people are making decisions just to further the interests of the business without figuring out how it leads to user happiness, the organization has become poisonous. It shouldn’t exist anymore. It might lurch on in a zombie state for quite some time. But it is on the decline, and all the good people will leave.
- charles_f 3y ago
  I had the same initial reaction. Seeing something written that can be amounted to $ > person looks wrong. Yet, importance is subjective. If you're working on your own pet code for your own pleasure, business has no importance. If you want to transform that into your main revenue source, business is the most important thing, because no amount of user love will transform into practical revenue if your software serves no-one.
  - bee_rider 3y ago
    If your project is useful to users and requires money to continue, it is in their interest that you make money. The business is just an abstraction around the fact that your users need you to be able to do the thing.
  - steamer25 3y ago
    It's not really $ > person. It's group of people A, who are conducting a [series of] transaction(s) with group of people B. It so happens that the wares being exchanged are currency vs. software but that's really besides the point. Group of people A ≹ Group of people B
- fritzo 3y ago
Retr0id 3y ago
> Code is a means to an end. Software should have a purpose, it’s supposed to provide a service to some user. I will accept this as a premise for the sake of argument, but it's certainly not a universal truth.
bcrosby95 3y ago
> Imaginary software Isn't this vaporware?
btown 3y ago
From the OP: > When I say “run” I don’t just mean executing a program; I mean operating it in production, with all that it entails: deploying, upgrading, observing, auditing, monitoring, fixing, decommissioning, etc. As Dan McKinley puts it: "It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it." One of the things separating a great developer from a good one, IMO, is the ability to treat the documented API boundary of an open-source library as something that isn't sacrosanct and impenetrable. How comfortable are you with command-clicking into, or outright cloning and reading, a library's source to understand the nuance that the documentation may not convey (or situation where the documentation is outright wrong)? Depending on your language's support for it, have you monkey-patched issues, or forked a library (and ideally submitted patches upstream) to add extension points you might need? Are you used to setting breakpoints inside of libraries, not just your own code, so you can understand how data is represented internally when debugging? And when you're evaluating whether to use a library in the first place, do you just look at the API and examples, or do you read the source to understand whether the underlying code prioritized maintainability, extensibility, and test coverage? Do you read changelogs and think about whether the library maintainers prioritize your ability to upgrade without breaking even your patched/forked code? The brilliance of open source is that we can do this. We're not just fitting gears together - we're able to fabricate iterations on those gears as we need to.
pjs_ 3y ago
Yeah man I press the gas more time than the brake but I still want the fuckin brakes to work...
gwbas1c 3y ago
> There’s a lot of software being produced that just doesn’t care about its users, or that manipulates them, or that turns them into the product. > There’s a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable Feels like one of the main plot points of Tron. (1980s Disney movie where programming was a major plot point.)
- idontpost 3y ago
  [dead]
gwbas1c 3y ago
> maintainer > author > usually a good investment to make the code maintainable by keeping it simple, writing tests and documentation I recently inherited a project where the leadership 100% believed this and tried to do it. The problem is that the copious junior developers they hired, with all of their good intentions, just couldn't write maintainable code.
- snoopsnopp 3y ago
  [dead]
malkia 3y ago
By that logic, I hope exception handling code is read more than run :)
Dig1t 3y ago
Also code is read way more times than it is written (or edited). So the corollary, in terms of concepts from my college programming languages class, is: reliability > readability > writability
siliconc0w 3y ago
The biggest stakeholder is change and accumulated cruft. The usefulness of code also drifts over time as the users, business, or paradigms/ecosystem changes. Most new code should be considered throw away until it's proven useful to end users. Once useful it can merged into 'stable' tree that should have high standards. Ideally 'stable' is capped at a certain size per the number of engineers and so to move code in requires refactoring or deleting dead or less useful code. The balance you want is to maintain high velocity but also allow for maintainability and core stability.
oglop 3y ago
This algebra doesn’t hold and the modals used are wrong. You can certainly build software that has a business purpose. Or not. I build useless software all the time, to learn. So the modal matters. I can build useless software. I can build useful software. Whether I should or shouldn’t is up to me. As for the rest, it’s a shakeup algebra. His inequalities don’t make sense in an academic environment for instance. But maybe that academic software then becomes open source and suddenly it’s huge! But at no point were he biz inequalities used. It’s a piece written from the environment of what looks to be private industry so maybe those algebras hold up better there. Also, the whole ops inequality made me laugh. If only this were true.
jurschreuder 3y ago
You should move as one, don't be so obsessed with the > then >
mattxxx 3y ago
I generally agree with the thesis here that "users and business are under-represented by people that are building and maintaining software", but the greater-than comparison over simplifies it, right? It's something like "Net revenue" and "net user happiness" trump "code prettiness". Additionally, in the "maintainer > user" scenario, is it all maintainers? Is it one particular maintainer that has strong opinions (maybe which don't reflect what the business cares about)? I'd suggest to replace the inequality mentality with an optimization problem, like: Find a version of the code that maximizes user happiness and minimizes maintenance cost. If there are two solutions that give roughly the same values for the above, then accept either.
shadowfoxx 3y ago
"There’s a lot of software being produced that just doesn’t care about its users, or that manipulates them, or that turns them into the product. And this isn’t limited to social media: as a user, I can’t even book a room, order food, or click on the Windows start button without popups trying to grab my attention;" I recently interviewed at Netflix and during the design portion of the interview I was tasked with navigating to a UI, creating a user-persona, and making arguments for or against how well the interface delivered on my goals as a user. I chose Amazon and "Parent of a family shopping for groceries". Mostly because I have a lot to say about the interface personally and I felt this would be useful in the interview. Now it used to be that when you clicked on the account section in the top right of the interface - the page would refresh and nothing would change. I found this infuriating because the dropdown was just a hover. Turns out the interface now takes you to a landing page with the same info as the hover. HOWEVER. During the interview, that hover (The one for Account), also advertised products to me. I mentioned that this is causing friction for me as a user, that what I want is to view my account information but I am being bombarded with more irrelevant things to buy. The interviewer - some lead of design within the company said - "Well, you have to remember that all of these decisions are tested to death and there is good likely good reason/research to back up that part of the UI". I wish I had the presence of mind to say that response betrays the exercise we were doing but I digress. Biz > dev > user. Biz ≹ user.
njharman 3y ago
My car is parked more than drive. Still, the drive is the more important, valueble, and difficult. Cars should be optimized for driving first, and only for other things when needed. Likewise code should be optimized for reading, which is to say for maintenance first, and for other things only if/when needed.
jiggawatts 3y ago
I have a corollary to this: there are a series of exponential increases in usage counts between each of: 1. Language designers & standard lib developers. 2. Shared module or library developers. 3. Ordinary developers. 4. End-users. For many languages, the ratios are on the order of 1,000x at each stage, so for each 1x language designer there might be 1,000 people designing and publishing modules for it, a million developers, and a billion users. Obviously these numbers change dramatically depending on the specific circumstances, but the orders of magnitude are close enough for a qualitative discussion. The point is that the tiniest bit of laziness at the first or second tiers has a dramatic multiplicative effect downstream. A dirty hack to save a minute made by someone "for their own convenience" at step #1 can waste literally millions of hours of other people's precious lives. Either because they're waiting for slow software, or frustrated by a crash, or waiting for a feature that took too long to develop at steps #2 or #3. It takes an incredible level of self-discipline and personal ethics to maintain the required level of quality in the first two steps. Conversely, it deeply saddens me every time I hear someone defending an unjustifiable position to do with core language or standard library design. "You just have to know the full history of why this thing has sharp edges, and then you'll be fine! Just be eternally vigilant, and then it's not a problem. As long as you don't misuse it, it's not unsafe/insecure/slow/problematic." is the type of thing I hear regularly when discussing something that I just know will be tripping up developers for decades, slowing down software for millions or billions.
2OEH8eoCRo0 3y ago
Code isn't run, machine instructions are run. Code is for reading and writing.
idkdotcom 3y ago
Great article! I make a living as a software engineer but my formal training is in electrical engineering (the applied math of the discipline). In EE, the mantra "if your design doesn't work is useless" was repeated ad nauseum. There was little to no credit to half working designs. Also in most EE products, specially semiconductors, the final product cannot be patched, so the emphasis on good design was immense. Come to the world of software engineer where the low barrier of entry attracts a lot of people interested mostly in making easy money. I have seen more horror code in my 10+ years as a software engineer than I can count. Some developers in particular those of the kind "I will spend 3 days coding nonstop with redbull" produce such shitty software that there is a name for them. John Ousterhout calls them "tactical tornados". I have had the misfortune of working side by side with a couple of tactical tornados and my life was miserable left to fix the mess they left behind once they left the company.
Too 3y ago
Cheap, fast, quality. Pick 2. Which one to pick isn’t as linear as the article portrays and it changes over time. You can’t religiously plant yourself in one corner of the triangle forever. Low quality will loose users and eventually also profit. Rushed development inevitably degrades quality over time, even if initially a high AWS bill hides this fact. No income and eventually you run out of cash to do any of the other 2.
codeflo 3y ago
The point is good. I found it a bit confusing that the article first collapses "author" and "maintainer" into "dev", and then randomly expands and recollapses them as the article goes on. The full inequality seems to be: biz > user > ops > maintainer > author That feels roughly right.
angarg12 3y ago
> It took me a while to fully grasp this because, in my experience, much of the software being built never really gets to production, at least not at a significant scale. If you work for organizations where most of the software built is never used, you have two options: influence your organization to greatly improve their efficiency, or look for a better place to work.

811 points by signa11 3y ago

Very nicely explained, as I kept reading it covered all my experiential "yes, but" thoughts. I will add that-knowing- all this is helpful, but implementing it when you are early in your career is hard. For example, it's good that Business is the big priority, but when you gave no experience of what is good, or bad, in business, it can be hard to understand the ramifications of decisions made now. Equally, business priorities should win, but your goals and the business goals may not be aligned. An individual may need to resume-pad (learn that new framework) while the business may want homogeneity (everything built on one framework.) Finally, of course, this refers to commercial software. Open Source software is the exact opposite flow, dev > maintainer > user > business. Which ultimately explains why it's so hard to get funding for OSS.

082349872349872 3y ago
Then again, the original ideal for OSS is that (just like owning a home is having the tenant and the landlord be the same person) devs and users are the same, so: (dev = ops = user) ≹ (biz).
goodpoint 3y ago
> Open Source software is the exact opposite flow, dev > maintainer > user > business That's a pretty sad assumption. "dev > user" is why a lot of projects have very poor usability.
- bruce511 3y ago
  Obviously it's not true for all projects. But it's true for most of them, no?
- zen928 3y ago
  devs have to use it to hoist it to a platform that can accessed by others before users can use it, right? imo users don't typically use open source software, they use generated artifacts from an upstream development process representing the capabilities of the software. users don't "use grafana", they use the implementation of how you deploy it. it should be improved upon by responses from the users who use your implementation, but what you're saying suggests that efforts like architecting your software in ways that improve/maintain development standards or packaging your software in a dependency manager before delivering any level of user facing feature is a sad assumption to you. I don't think the concern of usability here takes the entire picture of a project into context.

devjab 3y ago

I don’t think I agree with the sentiment that user doesn’t equal business, to some degree maybe, but a business is what its users produce. I buy the point that some users within a business can have a demand for processes that will not be good for the business because they may be too focused on their specific department, but as a whole I think they are largely the same thing. Happy users work better, better work is good for the business. Aside from that, I think a lot of the “bad” decisions are unavoidable as businesses grow, so too with the bureaucratic demands that are often not producing value, but it’ll be very hard for the “IT department” to do anything about it because it lives as a “service” department similar to HR, but less understood by management. Cost-centres never get political power to match money makers. I do think it’s a very interesting article, perhaps with a bit of a baiting headline. But I think it would be even better if it included the perspective of the modern ci/cd pipeline. What I mean by that is how we’re building more and more automation into it, things like RennovateBot that will automate certain parts of your maintenance processes. Things that won’t work automatically if you don’t write clean testable code. If you focus on delivering business value, spaghetti be damned, you’re going to end up spending so much time maintaining it that you’re eventually not going to be capable doing what you set out to do. We used to live on a world where this was sometimes ok, because you’d clean it up once the value was created, but with how much you can gain from a highly automated pipeline, I just don’t think that paradigm is true anymore. Because not only will you have to clean things up, you’re also going to miss out on so much efficiency by not being capable of using these automated tools. You can make the argument that you don’t need to update things as often as those tools help you so, and 5 years ago you would have been correct. Many places you may even still be correct, but in large organisations in the EU this is just no longer the case because of the added legislative bureaucracy that IT security needs to play into.

antoineMoPa 3y ago

I'm not sure I agree with everything, but I love the mental models this introduces.

drewcoo 3y ago

It is not about the comparative values of humans. It is about costs. The reason we write readable code is because we spend more time reading it than writing it. Engineer time. Which is money. Yes, other things are money considerations, too. Considerations the advice to write readable code is not meant to address.

quickthrower2 3y ago

I was sceptical but you know what, I love this mental model. Don’t follow it blindly of course, there are exceptions where dev > biz (see OpenAI debacle) and where dev > ops (early stage startup, move fast, in particular dev > ops because biz)

smt88 3y ago

For many of us, running our code 1 billion times will cost less than a few minutes of a developer's time. Hell, I could spend $200 for a month of server time on AWS and run a lot of my (web API) code 100 billion times. Optimizing for human readers is always better until you're working on something that proves itself to be too slow to be economical anymore.

krab 3y ago
In my experience, you need to care about latency. That affects user experience. It's quite hard to pay for better latency.
- groestl 3y ago
  You do that by paying for better developers ;)
- rezonant 3y ago
  That depends on the application and the use case, but good performance and good readability aren't mutually exclusive. Easy to read software might not always be the most performant, but it's far easier to improve performance in an easy to read codebase than it is to make a hard to read but performant codebase easier to read.
  - krab 3y ago
    Yeah, that's right. I just feel that latency is sometimes missing from the discussions re. developer efficiency vs paying more for compute.
    - josephg 3y ago
      Yep. Theres a huge experiential difference between something happening instantly and it happening in 200ms or so. Especially when typing or playing video games.
      - 3y ago

danielovichdk 3y ago

That's not the point. The point is that a computer is not involved in the creative and qualitative process, it does not care. Humans are different ad you might all know. So of course code should be readable over being runnable.

murkt 3y ago
You haven’t read the article past the headline, have you? It’s not about computers running code, it’s all about humans.
- danielovichdk 3y ago
  "It doesn’t matter how well written or maintainable the code is, nor how sophisticated the technology it uses if it doesn’t fulfill its purpose and provides a good experience to the user" This is what I was commenting on. And I do not agree with it because it underlines the dogma about how little craft quality means as long as someone finds it useful. You could also hammer 3 wooden boards together and call it a chair. But that's not for me, it's simply too shallow a mindset for being a professional software engineer.
  - johnnyanmac 3y ago
    >I do not agree with it because it underlines the dogma about how little craft quality means as long as someone finds it useful. YMMV vastly based on industry (or in the lens of this post, the demands and requirements on the user end to satisfy). For media, it's fine; very few users are going to suffer over a few minor bugs or an unoptimal system. For aerospace, it's fatal thinking for obvious reasons (with sadly, many real world examples to point to). Both are valid career aspects and both provide value. >it's simply too shallow a mindset for being a professional software engineer. sounds like you fall under "the right thing", as the author calls it. A sadly dying aspect as elephants and late stage capitalism (again, as the author named them) run wild. But I argue more that this is just fine for an engineer. You're thinking more like a professional computer scientist. scientists observe and model the nature around them. Engineers apply them, while taking into account the imperfections of nature and yes, humans. In my eyes, an engineer that can't adjust to the needs of the product (be it for biz, users, or someone that is not them) isn't an engineer, but a scientist. Or a craftman, as you deferred to ealier. Again, not a slight nor compliment, just different roles with different philosophies.

_nalply 3y ago

Because we as programmers need to know how to progam: learning trumps all. Thus: learning > biz > user > ops > maintainer > author There was that bit dev > * meaning resume-driven development, but in reality it is learning > * And that's the conflict programmers experience in corporate structures, for example the hassle programmers experience when they interview for a position. Employers know it too but they try to shirk it.

ahoka 3y ago
My gripe with most programmers that they keep re-learning the same narrow set of skills while ignore the rest that actually makes someone a efficient expert.
- f1shy 3y ago
  I could expand that though to a much larger set than programmers!
- sirsau 3y ago
  What do you think programmers ignore that would be beneficial?
  - codebolt 3y ago
    Their working domain. If you're a developer in financial services, learn finance. If you're a developer in oil exploration, learn seismology. Don't constrict yourself to only being a programmer who writes whatever code you're told to. Be a holistic problem solver.
    - rexpop 3y ago
      What's in it for me?
      - rob74 3y ago
        Maybe not needing to rewrite your code several times after being told that it's not what the client wanted to have?

solatic 3y ago

> And while we can’t just go back to ignoring the economic realities of our discipline, perhaps we should take a stronger ethical stand not to harm users. Acknowledging that the user may not always come before the business, but that the business shouldn’t unconditionally come first, either. This is why software engineering needs licensure. Not to check if people understand design patterns, or whether people know the fad library of the day, but to set clear ethical standards and hold people to those standards by disbarring them if they violate those standards. Or more to the point: society > biz > user > ops > dev

ametrau 3y ago
That’s really interesting. Barbers need a license (in Australia), lawyers need one, and yet people writing potentially crucial software do not.
- defrost 3y ago
  There's no shortage of hairdressing "institutes" in Australia promoting certificates awarded after passing their training courses and no doubt existing shops would look to see some evidence of skill before hiring .. however: Licensing/registration of hairdressers, beauty therapists and barbers is currently not required, legally binding or a symbol of any kind of standard in our industry. In previous times, there was a hairdresser’s trade license which was abandoned, without consultation with the industry. Re-establishing such a license would need to be done in conjunction with governments and education partners like TAFE’s and Private Colleges to ensure that the necessary awareness and legal processes are followed. Simply announcing that you are creating a license/registration for employees, and charging on the spot, simply won’t cut it. Hair & Beauty Australia Industry (2017): HAIRDRESSER LICENSE NOT NECESSARY AND NOT LEGAL https://www.askhaba.com.au/hairdresser-license-not-necessary-not-legal/ https://www.askhaba.com.au/hairdresser-license-not-necessary...
krzychukula 3y ago
IMHO. The article makes a wrong call to action. It calls for dev ethics when the problem is biz ethics. Instead of licensure wouldn’t it make more sense to have more rules and oversight for the companies?

gostsamo 3y ago

So, the author hijacks a perfectly good rule of thumb to build their grand theory of everything. It is all nice, clean, and wise, and besides the tortured turn of phrase is just rechewing of popular truisms.

rob74 3y ago
To say it more precisely, their grand theory of everything that can go wrong in software development. But interesting read nevertheless...
m463 3y ago
so: theory > /dev/null
- Planktonne 3y ago
  Beautiful.
- collyw 3y ago
  pragmatism > theory
- sltkr 3y ago
  blog < /dev/random
thomastjeffery 3y ago
Did you read to the end? Everything else is backstory.
gotski 3y ago
Honestly, I think there's value both in riffing off rules of thumb and using that riff to revisit and re-contextualise things we already think we know. Everything is new to someone, and even if this was just confirming my own biases I found it an interesting take.
deleted 3y ago
[deleted]

ekaramese 3y ago

It is filled with wisdom. I can not imagine the most genius programmers try to sell lingerie to people in google, facebook etc. purpose > *

YoshiRulz 3y ago

> There’s a lot of software being produced that just doesn’t care about its users [... caused by] a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable [... so] perhaps we should take a stronger ethical stand not to harm users. Or, we could ditch the "biz" part. It just so happens that software not written to serve business interests tends to also respect users.

vasco 3y ago
If we ditch the business part what's your recommendation to pay rent?
- cybrox 3y ago
  Just ditch the paying rent part.
- layer8 3y ago
  It's possible to get paid for writing software that secretly doesn’t solely serve business interests but also and even primarily repects users.
- YoshiRulz 3y ago
  I happen to believe in subsidised/affordable housing (I assume a UBI is what cybrox meant by not paying rent; also cracking down on housing-as-investments[1] sounds good to me, a layman, though apparently it wouldn't be enough[2] in our case, supply just needs to increase)—but I'm sure that other, less drastic societal changes would also be sufficient. For example, medium to large businesses could fund any open-source projects they make direct use of[3]. With the likes of OpenCollective[4][5] and GitHub Sponsors[6], the only roadblocks to adopting such a policy are corporate red tape and corporate greed. (And if it leads to smaller SBOMs, well, that's just a bonus as far as I'm concerned.) All that said, I was actually referring to individuals (who aren't necessarily developers) choosing which software to use. Over the last 20 years, we've all taken free downloads and sign-ups for granted, ignorant to that whole "if you're not paying, you're the product" thing, and a lot of us now have a $500+ supercomputer in our pockets which is to some extent owned by a tech giant and not its nominal owner. It's apparent that such centralised platforms have some intrinsic problems with regards to users' freedom. That's what I'm cautioning against—not the idea of selling your programming labour to a business, which is fine. [1]: https://en.wikipedia.org/wiki/Australian_property_bubble#Foreign_investment_in_residential_property https://en.wikipedia.org/wiki/Australian_property_bubble#For... (This article is outdated. From a quick web search, it seems foreign real estate investment fell during the pandemic but has now picked up again.) [2]: https://www.abc.net.au/news/2022-09-02/housing-property-australias-one-million-empty-homes/101396656 https://www.abc.net.au/news/2022-09-02/housing-property-aust... (1M unoccupied houses in a country of 26M, ~120k of whom don't have secure housing...) [3]: https://stackoverflow.blog/2021/01/07/open-source-has-a-funding-problem/#h2-e80da1e18ef10 https://stackoverflow.blog/2021/01/07/open-source-has-a-fund... [4]: https://blog.opencollective.com/funds-for-open-source/ https://blog.opencollective.com/funds-for-open-source/ [5]: https://docs.opencollective.com/help/financial-contributors/organizations/sustainer-resources https://docs.opencollective.com/help/financial-contributors/... [6]: https://docs.github.com/en/sponsors/sponsoring-open-source-contributors/sponsoring-an-open-source-contributor-through-github#sponsoring-accounts-in-bulk https://docs.github.com/en/sponsors/sponsoring-open-source-c...

gary_0 3y ago

"biz > user" is valid on paper because someone has to pay for the party; there are a finite number of software devs and capitalism is great at allocating scarce resources where they're most needed. Or at least the "spherical cows" version of free-market capitalism is great at that. In that version of capitalism, if your OS spends too much time putting spam in the Start Menu and not enough on fixing bugs, you can just switch to that other OS with full support from hardware vendors, that runs all your closed-source legacy software. If your favorite bird-themed social media site starts doing boneheaded stuff, you can just switch to that other site that has all your friends and data and lots of posts from experts and celebrities. If your search results are full of spam, you can switch to that other search engine with 10,000 highly paid engineers and 20 years of experience in Web search and integration with all your devices. And all the businesses you moved away from would have to clean up their act or go out of business. If only those cows were perfectly spherical.

thegrimmest 3y ago
Just because this doesn’t happen instantaneously doesn’t mean it’s a fantasy. Large changes in an ecosystem always take time. It may be years before the incumbents are truly displaced, but that doesn’t mean they won’t be. MySpace and RIM also seemed like they’d be there forever.
- gary_0 3y ago
  "In the long run, we're all dead."
- layer8 3y ago
  You'd have to explain your optimism of things eventually getting better, given that they've largely become worse over the past 10-15 years. Maybe it'll just be meandering around a mediocre-at-best mean level long-term.

bmitc 3y ago

> Software should have a purpose, it’s supposed to provide a service to some user. It doesn’t matter how well written or maintainable the code is, nor how sophisticated the technology it uses if it doesn’t fulfill its purpose and provides a good experience to the user: > user > maintainer > author This is completely wrong. To see why, replace the > signs with = and work backwards from there.

falserum 3y ago
Please elaborate.

BlackCherry 3y ago

This article codifies general power structures within organizations: who trumps who when making software decisions in an org and sells that status quo as some sort of useful rule of thumb, when it in fact has no utility at all.

kuldeepfouzdar 3y ago

Open source [not-for-profit] software says: Hello?

rob74 3y ago

TIL of ≹, which "articulates a relationship where neither of the two compared entities is greater or lesser than the other, yet they aren't necessarily equal either. This nuanced distinction is essential in areas where there are different ways to compare entities that aren't strictly numerical." (https://www.mathematics-monster.com/symbols/Neither-Greater-Than-nor-Less-Than.html https://www.mathematics-monster.com/symbols/Neither-Greater-...)

namanyayg 3y ago
Likewise, TIL. In your link however it states "Example 1: Numerical Context Let's consider two real numbers, a and b. If a is neither greater than nor less than b, but they aren't explicitly equal, the relationship is ≹" How can that be possible?
- magicalhippo 3y ago
  Perhaps this: if they represent angles, then 1 and 361 represents the same absolute orientation, but they're not the same as 361 indicates you went one full revolution to get there. Contrived, but only thing I could think of.
- thaumasiotes 3y ago
  It isn't. The real numbers are a totally ordered field. Any two real numbers are comparable to each other.
- shaunregenbaum 3y ago
  I would imagine trying to compare a purely imaginary number (3i) to a real number (3) would suffice.
  - thaumasiotes 3y ago
    An imaginary number wouldn't obey the stated constraint of being real.
    - 3y ago

e____g 3y ago

Counterpoint: machine code may be run often, but source code is run never.

ofey404 3y ago

A good article with a misleading name...

thomastjeffery 3y ago
Then again, it doesn't mislead very far.

rexpop 3y ago

To avoid violating my egalitarian principles, I choose to read ">" as "depends on."

vinay_ys 3y ago

The author's framing can be misunderstood in so many ways that it is not a useful shorthand at all. There can be no absolute rank order of these tokens. Firstly, in this framing, the "dev" is not one person but it is a collective for lots of people with varied expertise and seniority levels in different orgs – product, engineering and design orgs. Then, "ops" is again not one thing and not just engineering ops. It could be bizops, customer support etc. too. Then, "biz" isn't one thing either. There's branding/marketing/sales/legal etc. and execteam/board/regulators/lenders/investors etc. All of these people affect what code is written and how it is written and how and when it is shipped to users. Everyone should be solving the same "problem". A lot of the times, a lot of people within the org are just there to make sure that everyone understands/sees the same "problem" and is working towards the same goals. But that understanding is continuously evolving. And there is lag in propagation of it throughout the org. And hence, there is lag in everyone working towards the same goal – while goal itself is being evolved. Finally, "user" is not one thing either nor any one cohort of users are static. There are many different cohorts of users and these cohorts don't necessarily have long-term stable behaviors. So, it helps to understand and acknowledge how all the variables are changing around you and make sense of the imperfect broken world around you with that context. Otherwise it is very easy to say everyone else sucks and everything is broken and you want to restart building everything from scratch and fall into that and other well-known pitfalls.

hamdouni 3y ago

biz > user This one sounds like there is only the HN reality of dev : startups, VC, growth hacking, free until is not, client=product, burn every $ to reach monopoly,... But, there is another one with small businesses, craftsmanship, get what you pay, client=client...

jeffparsons 3y ago

Hey, author, if you end up reading this thread: put the conclusion on a sticker. I'll put one on my laptop and give a bunch to friends. For anyone that didn't make it to the end, the conclusion was: user > ops > dev biz > ops > dev biz ≹ user

karmakaze 3y ago
In the long run user > biz, otherwise users will be using a product of a different biz via the enshittification cycle.
- jeffparsons 3y ago
  Assuming a non-shit business, you could think of "biz" as "customers integrated over the long term". Therefore putting "users" and "biz" as incomparable could be interpreted as prioritising users, sustainably. At least that's how I interpret it.
- layer8 3y ago
  There are enshittified monopolies and oligopolies, with lots of moats.

hasoleju 3y ago

This article has opened up a new perspective for me. It articulates very well that software is a means to an end. It's a craft that can be used to solve a problem. In my past I often emphasized the craft part too much. As if only writing perfect code is all you need to do in order to be successful. The really important stuff is understanding the problem you want to solve and being sure that software is the tool to solve this particular problem.

cybrox 3y ago
The person understanding the problem to solve and the person crafting the solution don't necessarily need to be the same person, though. They can, in fact, be two people with completely different skill sets and if one of them ("you") can "only" write perfectly beautiful code, they can still succeed by relying on the other for breaking down the particular problem.

azangru 3y ago

I think what I am seeing in this article is a curious mixture of should and does. For example, the "user > dev" formula is a clear example of "should"; but when he gets to "biz > user", he surreptitiously switches to "does". He explains the biz > user by pointing out stakeholders, and investors, and personal interests, and politics, and all other sorts of crap that, in the real world, puts biz before the user. Very understandable. But should it? And why isn't the same explanatory method applied to the "dev > *" formula? After all, there are clearly very strong personal interests involved in that too.

C0mm0nS3ns3 3y ago
> But should it? How would it work if it wouldn't? He explains what he means by that. If you spend time and resources on all things the users require and your run out of money and go out of business, everybody loses. Of course you can take any of the "rules" and take them to an extreme where they become wrong. But I think if you don't push them to their breaking point they are good rules of thumb :)
- azangru 3y ago
  > How would it work if it wouldn't? He explains what he means by that. If you spend time and resources on all things the users require and your run out of money and go out of business, everybody loses. I think there is also a bit of a conflation of values vs ability. The formulas in the article represent values. Real life adds constraints based on what's possible. Consider his formula for dev vs user: "user > dev". You could argue that, just as a business is constrained by time and money, so is the developer constrained by time and skills. And yet, the author is happy with turning the greater than sign towards the user in this formula. Why?
  - deleted 3y ago
    [deleted]
  - filleduchaos 3y ago
    It's the same thing. If you bias your time and resources towards the things the dev require and/or would like and nobody actually wants to use the resultant software, you equally crash and burn and everyone loses. It's a priority ranking, not a zero-sum game.

kazinator 3y ago

Code being run more than read means this: code is read more by machine than by person. Users don't read code much, on the other hand. Thus: machine > maintainer > author > user QED

low_tech_punk 3y ago

I know this is considered wrong in so many ways, but my personal job satisfaction depends on dev > *, and in an ideal world, with open-source and end-user programming, we get user == dev > *

nehal3m 3y ago

I think the corollary to the title (to turn it around on the author) is not 'Code is read more than written' but 'code that can't be read won't run for long'. Disclaimer: Experienced sysadmin trying to make a lateral move to development and as such a complete noob.

rafaelmn 3y ago
> code that can't be read won't run for long There's plenty of ossified code people are scared to touch because they don't understand it, but stake their business on it :)
- thfuran 3y ago
  And even executables for which the source code has been lost but which are still important to business operations.
- Lutger 3y ago
  Or just code that works and nobody wants or needs to spend money on changing. I've written such code, very crappy stuff. And then coming back to the client many, many years later, finding it all just humming along, driving their business critical applications without it or the computer it runs on ever having been updated once in 5 years or so. I was so surprised, and a bit scared. Sometimes when you don't change anything, it just keeps working. So I guess that makes it a very boring: code that can't be read won't be changed and will not be relevant for long, but not always
- couchand 3y ago
  One of my clients is convinced that a short hunk of JavaScript code that nobody can clearly describe the behavior of is their most valuable asset. Non-coders are weird.
- LtWorf 3y ago
  I (very briefly) worked in a startup whose business was search (on a certain domain) and they had no tests for their "Search.java" file (the real name was 300x longer, because java devs…). I had found some operations to tweak the scoring, except that some were multiplications by one, so I removed them. But I got told to not touch them because they wouldn't know if I had broken it until some customer complained. The CTO told me off for my completely irresponsible behaviour.

j16sdiz 3y ago

> I can’t make a Google search without getting back a pile of garbage. I think SEO / Spammer share lots of that guilt. Not sure how to attribute them correctly.

xiphias2 3y ago
It's quite easy: Google giving better results than the minimum needed to make sure users don't switch is detrimental to its ads revenue. If you look at how many people are working on search at Google, it's just a small part at this point, vast amount of people at Google work on different ways of monetizing it.

deleted 3y ago

[deleted]

gloosx 3y ago

Quality article – for years of developing software, I have the bingo – heard and got used to every smell as long as there was air to breathe. I'm always in the end of this chain, doing the dirty work :)

atoav 3y ago

Also cars are driven more than repaired. Highways are used more than they need to be maintained. Yet if you don't include some thought to how to deal with a situation where something breaks, this could (and very likely: will) eventually come back to haunt you. But code is not the same as your car. If money is not an issue and your car breaks you could just get another one that drives equally well. Try doing that if your code breaks. So whether values like readability, maintainability etc. can be important for good code is out of the question — what remains an open question is (on a per file basis) how to priorize between those two if such a need arises. And that isn't a small "if": One should guard themselves against the simple thought that these are inevitable tradeoffs that are mutually exclusive. You can easily make code that is both unreadable and doesn't run well. You can also make extremely readable code that runs nearly perfectly. The latter is of course harder than writing the same code to just run well, but if you are not coding alone or your project is beyond a certain scale it might be well worth the extra thought. The solution space for "clear structure" and "good performance" is smaller than for either of those alone, so finding a good solution here is a bigger challenge, but depending on what you plan to do it could be worth a try.

rafaelmn 3y ago

You have to have something worth running first.

rtpg 3y ago

Kind of funny, but I have seen code that is indeed read more than is run, at least for the first year or two of its existence. Code that is used for generating batch reports for some billing process would run once a month. But I had to spend a lot of time staring at it, wondering what is going on, and fixing things up as reports came in. One could say that the test runs were run more than the code was read (of course), but in production? Definitely the same order of magnitude for a long time.

shenbomo 3y ago

[flagged]

deleted 3y ago

[deleted]

otikik 3y ago

I expected to be very defensive when reading the title but I actually fully agree with the article, thank you for sharing

deleted 3y ago

[deleted]

emrahcom 3y ago

Needed to define customers and users separately

t43562 3y ago

Some users are not using a system because they like it but because their company bought it. In those situations biz > user by definition and the developers end up having to cater to the needs of the middle managment of their customers rather than the needs of the actual users. The price of not doing this is failing to win the contract. Users then get locked in to whatever crap you have time to provide for them while you're really busy implementing new features that middle managment like. You essentially only need a nice looking login screen and some sort of reporting and the rest.....doesn't matter much. I am being a bit cynical but it does pay as an engineer to know if that's fundamentally the kind of company you're in. An online retailer, for example, is hypersensitive to its users and I know of at least one that has different versions of its website for different countries because they know that Germans like X and Americans like Y - small changes make a huge difference to sales. Other companies have no sensitivity to the usability of their products because the people who buy their products are never the users.

derangedHorse 3y ago
Typically middle management are users as well, but they are a minority of the user base and use a different set of features (like reporting). So now this becomes a question of which users are prioritized and finding a balance between prioritizing the experience of the small number of users who hold power over the rest, and keeping the product usable enough for the rest of the users to provide some value in data to management.
- pixl97 3y ago
  Or as I've told the devs in the place I work "Don't fuck up the data path to the reports, it is a cardinal sin".
bluGill 3y ago
This is short term thinking - users who hate software can voice enough complaints to get things changed in at least some situations. (not all: many SAP programs with garbage UIs exist)
- 3y ago

Alifatisk 3y ago

Code is run more than read. Code is read more than written. Code is written more than ...?

tomovo 3y ago
...correct?
- Alifatisk 3y ago
  "tested" feels more suitable
collyw 3y ago
tested

redhale 3y ago

I'm not sure I've ever read an article where so many times I thought "ok fine, but ..." only to have the next paragraph address that exact point each and every time. The ending point especially. As others here have pedantically pointed out (as HN is wont to do), there are ways to misinterpret or muddle some of the phrasing used here. But I think that's true of any reasonably simple (and therefore broadly useful) mental model. To me, this is a useful way of framing these ideas at a high level.

lhnz 3y ago

The article is good on the whole but the title "Code is run more than read" seems false in many situations I've been in. A lot of software doesn't have users. Often the target users don't like the product enough and are just trialing it for you as a favour. In these cases, it's not very meaningful to say it's being "run more than read", because either you should have made the code readable enough for other developers to delete it, modify it or rewrite it until users want to use it, or the code has to be valueless and able to be completely thrown away (the knowledge of how to build it is either written down elsewhere or tacit). I also agree with what somebody else said about the times in which the features/fixes you create aren't seen by users but just benefit a business-to-business sales process. In these cases, you behave differently. You do the work because there's a very clear signal to your company meeting their expectations promptly. I guess one way I would agree with the article is that once something has users/businesses and is somewhat readable you apply your extra effort on polishing the user experience as prioritising the happiness of your core users is generally a good idea.

amai 3y ago

I like the clean design of this blog. Is is very well readable on my smartphone.

xpe 3y ago

I'm glad to see something approaching ethics discussed: > There’s a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable, and I think that explains the increasing discomfort of many software professionals. "Discomfort" is quite the understatement. This leaves so much unsaid. I will add some questions: - What happens when your users are not your customers (the ones that pay)? - Does your business have any ethical obligation to your users -- all of them -- even the ones that do not pay? - What happens when your paying customers seek to use your business in ways that have negative downstream effects for your users? For example, what if: - Your platform makes fraud easier than the existing alternatives? - Your platform makes it easier to misinform people in comparison to the alternatives? - Your platform makes it easier to shape user opinions in ways that are attractive (habit-forming) but destructive in the long-term? All of these have proven to be successful business models, over some time scales! Given the reality of the dynamic, should a business pursue such an exploitative model? If so, can it do so more or less responsibly? Can a more ethical version of the business mitigate the worst tendencies of competitors? Or will it tend to become part of the problem? A key take-away is clear: some classes of problems are bigger and more important than the business model. There are classes of problems that can be framed as: what are the norms and rules we need _such that_ businesses operate in some realm of sensibility? Finally, I want to make this point crystal clear: a business inherently conveys a set of values: this is unavoidable. There is no escaping it. Even if a business merely takes the stance of 'popularity wins', that is in itself a choice that has deep implications on values. Political scientists and historians have known for years about the problems called 'tyranny of the majority'. Food for thought, no matter what your political philosophy. I don't know 'the best' set of ethics, but I know that some are better than others. And I hope/expect that we'll continue to refine our ethics rather than leave them unexamined. [Updates/edit complete as of 8:03 AM eastern time]

ebiester 3y ago
I believe this is a different problem than the essay is speaking about. You can choose what problems and domains fit your ethics. This is about how you build a system and how you prioritize the work.

WolfOliver 3y ago

Nice article, I always had the impression that we value DX a little too much. I mean developers are paid to do the jobs, but users are not.

bogrollben 3y ago

Nice article. I'd like to point out that a mature/legacy codebase contains every example listed under the "smell" section of the article, sometimes even within the same file. This creates a great deal of complexity to unwind beyond the mere coding of it all.

nikanj 3y ago
And an enterprising code keener will insist on rewriting that legacy codebase to eliminate all "smells", replacing battle-tested, bug-free-but-bad-smelling code with fresh, elegant, untested and nice code. Every generation relearns this the hard way, this blog post is 23 years old today and still 100% on the money https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

a_c 3y ago

I think the message is very profound. It is one of the message like "eat your veg, exercise, sleep well, love your family". On surface one would respond "yeah who doesn't get that". Who doesn't know software is as good as getting used? Oh wait, but no, what about knowledge, wealth, career, fame, status, entertainment and so many more. What about architecture, maintainability, scalability, trendiness, developer experience, team management, OKR, career prospect, and others? A punch is a punch. Software is about getting used. (I swapped user with used, IME user can mean different things to different people)

deleted 3y ago

[deleted]

HPsquared 3y ago

CPUs are lower in the hierarchy than developers.

timeon 3y ago

Just side note. Article is written in context of business. But sometimes there is non, like public sector. Nevertheless, article covered this context in the end as well.

asylteltine 3y ago

Rolled my eyes at the capitalism comment. Was that really necessary? Idealism > logic

Nevermark 3y ago

For enterprise software: Customer > User ??

bee_rider 3y ago

Businesses don’t really exist, they are an imaginary construct that we’ve come up with to help organize resources, ultimately in the interests of working together. Business isn’t more important than anything. There are multiple users, sometimes with competing interests; you can’t be everywhere and everything, so you have to prioritize. Going after more profitable users or users that align with some long-term strategy could be seen as “good for the business,” but really the goal is to serve the users (it might just take a couple extra steps). When the internal politics get confused to the point that people are making decisions just to further the interests of the business without figuring out how it leads to user happiness, the organization has become poisonous. It shouldn’t exist anymore. It might lurch on in a zombie state for quite some time. But it is on the decline, and all the good people will leave.

charles_f 3y ago
I had the same initial reaction. Seeing something written that can be amounted to $ > person looks wrong. Yet, importance is subjective. If you're working on your own pet code for your own pleasure, business has no importance. If you want to transform that into your main revenue source, business is the most important thing, because no amount of user love will transform into practical revenue if your software serves no-one.
- bee_rider 3y ago
  If your project is useful to users and requires money to continue, it is in their interest that you make money. The business is just an abstraction around the fact that your users need you to be able to do the thing.
- steamer25 3y ago
  It's not really $ > person. It's group of people A, who are conducting a [series of] transaction(s) with group of people B. It so happens that the wares being exchanged are currency vs. software but that's really besides the point. Group of people A ≹ Group of people B
fritzo 3y ago

Retr0id 3y ago

> Code is a means to an end. Software should have a purpose, it’s supposed to provide a service to some user. I will accept this as a premise for the sake of argument, but it's certainly not a universal truth.

bcrosby95 3y ago

> Imaginary software Isn't this vaporware?

btown 3y ago

From the OP: > When I say “run” I don’t just mean executing a program; I mean operating it in production, with all that it entails: deploying, upgrading, observing, auditing, monitoring, fixing, decommissioning, etc. As Dan McKinley puts it: "It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it." One of the things separating a great developer from a good one, IMO, is the ability to treat the documented API boundary of an open-source library as something that isn't sacrosanct and impenetrable. How comfortable are you with command-clicking into, or outright cloning and reading, a library's source to understand the nuance that the documentation may not convey (or situation where the documentation is outright wrong)? Depending on your language's support for it, have you monkey-patched issues, or forked a library (and ideally submitted patches upstream) to add extension points you might need? Are you used to setting breakpoints inside of libraries, not just your own code, so you can understand how data is represented internally when debugging? And when you're evaluating whether to use a library in the first place, do you just look at the API and examples, or do you read the source to understand whether the underlying code prioritized maintainability, extensibility, and test coverage? Do you read changelogs and think about whether the library maintainers prioritize your ability to upgrade without breaking even your patched/forked code? The brilliance of open source is that we can do this. We're not just fitting gears together - we're able to fabricate iterations on those gears as we need to.

pjs_ 3y ago

Yeah man I press the gas more time than the brake but I still want the fuckin brakes to work...

gwbas1c 3y ago

> There’s a lot of software being produced that just doesn’t care about its users, or that manipulates them, or that turns them into the product. > There’s a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable Feels like one of the main plot points of Tron. (1980s Disney movie where programming was a major plot point.)

idontpost 3y ago
[dead]

gwbas1c 3y ago

> maintainer > author > usually a good investment to make the code maintainable by keeping it simple, writing tests and documentation I recently inherited a project where the leadership 100% believed this and tried to do it. The problem is that the copious junior developers they hired, with all of their good intentions, just couldn't write maintainable code.

snoopsnopp 3y ago
[dead]

malkia 3y ago

By that logic, I hope exception handling code is read more than run :)

Dig1t 3y ago

Also code is read way more times than it is written (or edited). So the corollary, in terms of concepts from my college programming languages class, is: reliability > readability > writability

siliconc0w 3y ago

The biggest stakeholder is change and accumulated cruft. The usefulness of code also drifts over time as the users, business, or paradigms/ecosystem changes. Most new code should be considered throw away until it's proven useful to end users. Once useful it can merged into 'stable' tree that should have high standards. Ideally 'stable' is capped at a certain size per the number of engineers and so to move code in requires refactoring or deleting dead or less useful code. The balance you want is to maintain high velocity but also allow for maintainability and core stability.

oglop 3y ago

This algebra doesn’t hold and the modals used are wrong. You can certainly build software that has a business purpose. Or not. I build useless software all the time, to learn. So the modal matters. I can build useless software. I can build useful software. Whether I should or shouldn’t is up to me. As for the rest, it’s a shakeup algebra. His inequalities don’t make sense in an academic environment for instance. But maybe that academic software then becomes open source and suddenly it’s huge! But at no point were he biz inequalities used. It’s a piece written from the environment of what looks to be private industry so maybe those algebras hold up better there. Also, the whole ops inequality made me laugh. If only this were true.

jurschreuder 3y ago

You should move as one, don't be so obsessed with the > then >

mattxxx 3y ago

I generally agree with the thesis here that "users and business are under-represented by people that are building and maintaining software", but the greater-than comparison over simplifies it, right? It's something like "Net revenue" and "net user happiness" trump "code prettiness". Additionally, in the "maintainer > user" scenario, is it all maintainers? Is it one particular maintainer that has strong opinions (maybe which don't reflect what the business cares about)? I'd suggest to replace the inequality mentality with an optimization problem, like: Find a version of the code that maximizes user happiness and minimizes maintenance cost. If there are two solutions that give roughly the same values for the above, then accept either.

shadowfoxx 3y ago

"There’s a lot of software being produced that just doesn’t care about its users, or that manipulates them, or that turns them into the product. And this isn’t limited to social media: as a user, I can’t even book a room, order food, or click on the Windows start button without popups trying to grab my attention;" I recently interviewed at Netflix and during the design portion of the interview I was tasked with navigating to a UI, creating a user-persona, and making arguments for or against how well the interface delivered on my goals as a user. I chose Amazon and "Parent of a family shopping for groceries". Mostly because I have a lot to say about the interface personally and I felt this would be useful in the interview. Now it used to be that when you clicked on the account section in the top right of the interface - the page would refresh and nothing would change. I found this infuriating because the dropdown was just a hover. Turns out the interface now takes you to a landing page with the same info as the hover. HOWEVER. During the interview, that hover (The one for Account), also advertised products to me. I mentioned that this is causing friction for me as a user, that what I want is to view my account information but I am being bombarded with more irrelevant things to buy. The interviewer - some lead of design within the company said - "Well, you have to remember that all of these decisions are tested to death and there is good likely good reason/research to back up that part of the UI". I wish I had the presence of mind to say that response betrays the exercise we were doing but I digress. Biz > dev > user. Biz ≹ user.

njharman 3y ago

My car is parked more than drive. Still, the drive is the more important, valueble, and difficult. Cars should be optimized for driving first, and only for other things when needed. Likewise code should be optimized for reading, which is to say for maintenance first, and for other things only if/when needed.

jiggawatts 3y ago

I have a corollary to this: there are a series of exponential increases in usage counts between each of: 1. Language designers & standard lib developers. 2. Shared module or library developers. 3. Ordinary developers. 4. End-users. For many languages, the ratios are on the order of 1,000x at each stage, so for each 1x language designer there might be 1,000 people designing and publishing modules for it, a million developers, and a billion users. Obviously these numbers change dramatically depending on the specific circumstances, but the orders of magnitude are close enough for a qualitative discussion. The point is that the tiniest bit of laziness at the first or second tiers has a dramatic multiplicative effect downstream. A dirty hack to save a minute made by someone "for their own convenience" at step #1 can waste literally millions of hours of other people's precious lives. Either because they're waiting for slow software, or frustrated by a crash, or waiting for a feature that took too long to develop at steps #2 or #3. It takes an incredible level of self-discipline and personal ethics to maintain the required level of quality in the first two steps. Conversely, it deeply saddens me every time I hear someone defending an unjustifiable position to do with core language or standard library design. "You just have to know the full history of why this thing has sharp edges, and then you'll be fine! Just be eternally vigilant, and then it's not a problem. As long as you don't misuse it, it's not unsafe/insecure/slow/problematic." is the type of thing I hear regularly when discussing something that I just know will be tripping up developers for decades, slowing down software for millions or billions.

2OEH8eoCRo0 3y ago

Code isn't run, machine instructions are run. Code is for reading and writing.

idkdotcom 3y ago

Great article! I make a living as a software engineer but my formal training is in electrical engineering (the applied math of the discipline). In EE, the mantra "if your design doesn't work is useless" was repeated ad nauseum. There was little to no credit to half working designs. Also in most EE products, specially semiconductors, the final product cannot be patched, so the emphasis on good design was immense. Come to the world of software engineer where the low barrier of entry attracts a lot of people interested mostly in making easy money. I have seen more horror code in my 10+ years as a software engineer than I can count. Some developers in particular those of the kind "I will spend 3 days coding nonstop with redbull" produce such shitty software that there is a name for them. John Ousterhout calls them "tactical tornados". I have had the misfortune of working side by side with a couple of tactical tornados and my life was miserable left to fix the mess they left behind once they left the company.

Too 3y ago

Cheap, fast, quality. Pick 2. Which one to pick isn’t as linear as the article portrays and it changes over time. You can’t religiously plant yourself in one corner of the triangle forever. Low quality will loose users and eventually also profit. Rushed development inevitably degrades quality over time, even if initially a high AWS bill hides this fact. No income and eventually you run out of cash to do any of the other 2.

codeflo 3y ago

The point is good. I found it a bit confusing that the article first collapses "author" and "maintainer" into "dev", and then randomly expands and recollapses them as the article goes on. The full inequality seems to be: biz > user > ops > maintainer > author That feels roughly right.

angarg12 3y ago

> It took me a while to fully grasp this because, in my experience, much of the software being built never really gets to production, at least not at a significant scale. If you work for organizations where most of the software built is never used, you have two options: influence your organization to greatly improve their efficiency, or look for a better place to work.