Code is run more than read
olano.dev
olano.dev
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.
We needed to win contracts, so we needed to tick their checkboxes, but we also cared for the user experience (good UX was almost never a strict requirement from our customer).
Our competitors' software was very painful to use, so we wanted to differentiate in this regard.
This made our own lives easier as the training was easier, the users we interacted with (that usually had no say in whether our solution was bought to them or our competitors') were happier and recommended to their managers (where they could) buying more stuff from us.
In the end this was 80% driven by pride (our software doesn't suck) and empathy (I couldn't stand using the software if it was as bad as our competitors') but to some extent this was also in our interest (especially in the long term, where your brand is built).
And then the happy users switch to another company and start recommending your stuff to their new managers. It's an extra source of leads and sales :-)
Unfortunately that works until some brilliant mba shows up with a plan to sell 100x more consulting and more training by making the product intentionally much more difficult to use.
It was a doomed approach. We needed salespeople to get inside the heads of the purchasers, learn how to explain the benefit to them, and coach the users on explaining the benefits to other people in their organization. We needed salespeople to bridge the chasm between the users and the purchasers.
I remember being in site meetings where people who used it every day would tell us to our face how terrible it was. Without fail, that site renewed with some promises to fix a couple specific bugs and a minimal price increase.
this is why all enterprise software sucks
This is why I use Windows and Visual Studio at work. I don't like either of them, but it's not my call.
SAP absolutely delights its users to the tune of a $200 billion market cap.
Take one look at EMRs and realize that its sold / marketed to .01% of the hospital, despite 80% of the health system using it.
Again, you can exclusively cater to management, but you don’t have to. Look at Datadog. It’s a great product, but still ultimately purchased by management.
From my observations, it's usually not that devs are lazy or lack a sense of craft, it's that their employers are not willing to spend money building something that isn't actually a requirement.
or worse think they are good at it. Then guard that GUI like it is their first born.
Can you speak any more to this? Do you or anyone else have any examples? I would be very interested to see.
Then again, I’m not saying much that vendors screw up pricing when they choose a price other than “$0,” which is an essential part of B2B-disguised-as-B2C software. Easy for me to say.
Anyway, the boomers you are talking about are retiring out of the workforce, and it will be more likely than ever that the audience will be extremely sensitive to UX, desiring something the most like TikTok and Instagram than ever.
Slack in particular had to take a just-OK buyout from Salesforce and the product has seriously stagnated.
Your uses of "every" and "big" here seem idiosyncratic.
> To conclude, the ≹ symbol plays a crucial role in providing a middle ground between the traditional relational operators.
As a PhD student in math, I have never seen it before. I do not believe that it plays any crucial role.
This symbol for it may be useful, but it's the concept that matters.
I really love that video.
The space of possible abstractions for any given phenomenon is vast, yet we almost always just assume that real numbers will do the trick and then begrudgingly allow complex ones when that doesn't work. If we're not lucky we end up with the wrong tool for the job, and we haven't equipped people to continue the exploration. It's a bias with some pretty serious consequences (thanks... Newton?).
I don't think I've seen the inadequacy of number-systems-you've-heard-of demonstrated so clearly as it is done here.
Well, don't leave us hanging! What are some of your favorite hot games on top of switches?
So you can end up with a sequence "d > b > a" and "d > c > a", but "c ≹ b".
Defining how tie-breaking for those cases are deterministically performed is a big part of the problem that CRDTs solve.
"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?
But the numerical context can still be correct: (edit: ~~imaginary~~) complex numbers for example don’t have such a property.
Note that Games do _not_ form a field: there is no general multiplication operation between arbitrary games.
Or more generally, vectors. They don't have a total order, because as we define "less than"/"greater than" in terms of magnitude (length), this means for any vector V (other than 0), there's an infinitely many vectors that are not equal to V, but whose length is equal to length of V.
Is this is what ≹ is talking about?
Imagine you have 2 irrational numbers, and for some a priori reason you know they cannot be equal. You write a computer program to calculate them to arbitrary precision, but no matter how many digits you generate they are identical to that approximation. You know that there must be some point at which they diverge, with one being larger than the other, but you cannot determine when or by how much.
The 1/3 * 3 argument, I found the most intuitive.
All the decimals that recur are fractions with a denominator of 9.
E.g. 0.1111.... is 1/9
0.7777.... is 7/9
It therefore stands to reason that 0.99999.... is 9/9, which is 1
The geometric series proof is less fun but more straightforward.
As a fun side note, the geometric series proof will also tell you that the sum of every nonnegative power of 2 works out to -1, and this is in fact how we represent -1 in computers.
Edit: Not in many programming languages. In IEEE-754 inf == inf. In SymPy too oo == oo, although it's a bit controversial. Feels sketchy.
Now if you really think about, a number of a given magnitude on x axis also isn't exactly "equal" to a name of same magnitude on y axis or vice versa. Other wise, -5 and 5 should be equal, because they're the same magnitude from 0.
Edit: oh, I see what you mean. 1 is not larger or smaller than i, but it also doesn't equal i.
I've never really seen this notation used, but it could have some use in partially-ordered sets.
You could imagine two fuzzy numbers with the same 'crisp' number having different membership profiles, and thus not being "equal", while at the same time being definitely not less and not greater at the same time.
Having said that, this all depends on appropriate definitions for all those concepts. You could argue that having the same 'crisp' representation would make them 'equal' but not 'equivalent', if that was the definition you chose. So a lot of this comes down to how you define equality / comparisons in whichever domain you're dealing with.
Contrived, but only thing I could think of.
(a+b)^2 != a^2 + b^2
Strictly you should write something like
¬[∀ a,b (a+b)^2 != a^2 + b^2]
The question is why the page says "imagine two real numbers that aren't comparable".
\inf and $\inf + 1$ comes to mind but I don't think it really counts
That just depends on the numeric structure you're working with. In the extended reals, +inf is equal to +inf + 1.
In a structure with more infinite values than that, it would generally be less. But they wouldn't be incomparable; nothing says "comparable values" quite like the pair "x" and "x + 1".
It really is an interesting thing. In fact, as human beings who by nature think in terms of abstract, non-concrete units (as opposed to mathematically precise units like a computer program), we tend to compare two related things. They might belong to the same category of things, but they might not be eligible for direct comparison at all.
Once you internalize partial ordering, our brain gets a little more comfortable handling similar, yet incomparable analogies.
Such a thing is called a partial ordering and a set of values with a partial ordering is called a partially ordered set or poset (pronounced Poe-set) for short.
The author of the original article uses it correctly - think about it more in regards to importance for their example.
The business is no more or less important than the developer, but they are NOT equal.
It doesn't have to mean importance though, just the method by which you are comparing things.
Monday ≹ Wednesday
Come to think of it, it should be called the 'No better than' operator.
Not in a partial order.
For example in this simple lattice structure, where lines mark that their top end in greater than their bottom end:
11
/ \
01 10
\ /
00
You can actually see this kind of structure everyday: unix file permissions for example. Given a user and a file, the permissions of the user are is an element of a lattice where the top element is rwx (or 111 in binary, or 7 in decimal, which means the user has all three permissions to read, write, and execute) and the bottom element is --- (or 000, in binary, or 0 in decimal, which means the user has no permissions). All other combination of r, w, and x are possible, but not always comparable: r-x is not greater nor lesser than rw- in the permissions lattice, it's just different.
That’s only true for a total order; there are many interesting orders that do not have this property.
It holds for the usual ordering on N, Z, Q and R, but it doesn’t hold for more general partially ordered sets.
In general one has to prove that an order is total, and this is frequently non-trivial: Cantor-Schröder-Bernstein can be seen as a proof that the cardinal numbers have a total order.
For example, set inclusion. Two different sets can be neither greater than not smaller than each other. Sets ordered by inclusion form a partially ordered lattice.
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.
user > ops > dev
biz > ops > dev
biz ≹ user
Or they picked a title that would let you rapidly spot who didn't even skim the article.
(And most of your users don't have developer's salary, or developer's quality of life, so it hurts them that many times more.)
--
[0] - Yes, wasting someone's time reduces QALY.
> that by making the code better for the user,
Did you mean the dev?
Abstractions MIGHT make your code slower. But there's a reason we're not using assembly: Because the minor efficiency hit on the software doesn't match up with the bugs, the salary towards the experts, the compilation errors, etc.
A VM is a pretty good tradeoff for users, not just devs.
[0] https://en.m.wikipedia.org/wiki/Quality-adjusted_life_year
> 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
the inference process in article is interesting, but title tempt us to debate about a less related topic.
thanks for your comments let me finish reading.
If you don't fit in the budget for the specific task, your product features don't matter much.
Like I said, it works until it doesn't, and then you do have to optimize for performance to some extent.
Some LLVM-based language would fit the bill better, like Rust, C (also true of the intel compiler and gcc), C++, etc.
This sort of calculations you preach are inherently untrue, as they completely ignore that 1second times million. After all, nobody bothers economically evaluate just a single second. But it does account to much, when multiplied by the ammount of users. And when we multiply again, by the times a single user uses your software, and then again, by the time a users uses different software from other developers who also thought "it's only 1 second, nobody cares", we end up living in world where software usability gets lower and lower despite hardware getting faster and faster.
We end up living in a world where literally weeks are wasted everyday, waiting for slow windows file explorer. If you'd want to evaluate that honestly, you would probably come to conclusion that microsoft should have a dedicated team, working for decade on nothing but explorer startup optimization, and it would still pay for it self.
But they don't. Because at the end of the day, this whole "lets evaluate developers time working on given improvement" is just a cope and justification of being us lazy, that only pretends to be an objective argument so we can make ourself feels better
So running the software includes more than just the server costs.
Another way of stating the relationship could be something like: You have fewer brain-cycles to apply to optimization than the combined sum of everyone who will ever read your code, if your code matters. But that is a mouthful and kind of negative.
There's plenty of ossified code people are scared to touch because they don't understand it, but stake their business on it :)
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 alwaysNon-coders are weird.
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.
I'm sure it has happened more than once.
I'd say it's more 'code that can't be read won't be modifiable for long'.
Bad news: too few experienced ops people became one less!
1. Language designers & standard lib developers.
2. Shared module or library developers.
3. Ordinary developers.
4. End-users.
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.
theory > /dev/null blog < /dev/randomUsual reminder that many people in our industry are not native speakers and don't live in an English speaking country, and yet they make the effort to write in English, which may explain the "tortured turn of phrase".
> just rechewing of popular truisms
And yet these "popular truisms" are particularly well put together in a coherent way, which makes this post a useful reference.
Everything is new to someone, and even if this was just confirming my own biases I found it an interesting take.
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.
> 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]
Hardly. I'll quote the last paragraph and the three inequalities:
> 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. 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:
user > ops > dev
biz > ops > dev
biz ≹ user
Second, "the user may not always come before the business, but that the business shouldn’t unconditionally come first". This is very much aligned with my question "what are the norms and rules we need _such that_ businesses operate in some realm of sensibility?"
...
Ok, putting aside debates around the author's intent or 'valid scope' of this discussion (which by the way, is a rather organic thing, computed lazily by the participants, rather than by fiat), I'd like to add some additional thoughts...
In much of the software world there is a mentality of "We'll figure out Problem X (such as a particular problem of scaling) if we get to that point." I'll make this claim: naively deferring any such problems that pertain to ethics are fraught. Of course there are practical considerations and people are not angels! For precisely these reasons, ethics must be something we study and put into practice before other constraints start to lock in a suboptimal path.
I often look at ethics from a consequentialist point of view that includes probabilities of system behavior. This could be thought of as computing an 'expected future value' for a particular present decision.
If one applies such an ethical model, I think the impacts of choices become clearer. And it becomes harder to use false-choice reasoning to demonize others and exonerate ourselves. For example, if a particular business model has a significant probability of harming people, one cannot claim ignorance much less complete innocence when those harms happen. They were no surprise, at least to people who pay attention and follow the probabilities.
Ascribing blame is quite difficult. I like to think of blame as being a question largely of statistical inference. [1] But even if we all agreed to a set of ethical standards, the statistical inference problem (multicollinearity for example) would remain. There is plenty of blame to go around, so to speak. But certain actions (very highly influenced by mental models and circumstances) contribute more than others. [2]
To what degree is ignorance an ethical defense? This is a tough one. Not all people nor entities have the same computational horsepower nor awareness. I don't have the answers, but I have not yet found a well-known ethicist in the public eye that speaks in these terms to a broad audience. To me, the lack of such a voice means I need to find more people like that and/or contribute my voice to the conversation. The current language around ethics feels incredibly naive to my ears.
[1] I agree that for most people, ethical rules of thumb get us 'most of the way there'. But these heuristics are imperfect.
[2] To be clear, I see blame as often overused. I care relatively less about blaming a person for mistakes. I care much more about what a person's character tells us about how they will behave in the future. That said, a corporate entity is not a person deserving of such generosity. Corporate entities are not first-class entities deserving human-rights level protection. A legal entity is a derivative entity; one created in the context of laws which should rightly function to better the society in which it is formed. A corporate entity can rightly be judged / evaluated in terms of its behaviors and internal structure and what this entails for its future likely behavior. We don't expect corporate entities to be charities, for sure, but we also didn't consciously design the legal environment so that corporate entities can actively undermine the conditions for a thriving society with impunity.
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.
Businesses exist in as much as they are the primary determinant of most people's lives. They shape our cities, our media, laws, politics, foreign policy and have a huge impact in just about everything else that matters. Real or not, it has _real_ impacts all around us.
Outside of OSS, I think it's pretty clear that the entity that's footing the bill gets to make the call on how things get made. Even if that's: bad for said entity, bad for the user, bad for the public generally, the environment, etc. (of course, there's industry and governmental regulations, but by and large the company calls the shots).
By this standard, ancient religious figures (now mostly regarded as mythological) exist. Thor, or Zeus (if anyone is a pagan here, I don’t mean any disrespect to your beliefs, but let’s think about whichever one you don’t believe in).
> Real or not, it has _real_ impacts all around us.
Sure. But people were much more devoted to these figures than any business! Religious wars were fought, people lived and died for these gods. But some of these figures still were imaginary. Being imaginary doesn’t mean they aren’t important. But it means they don’t have interests. In reality, these organizations (religions, businesses) have members, users, and leaders/owners, and the business is an abstract representation of those people.
That’s why it doesn’t make sense to ask whether “the business,” which exists entirely as an abstraction for some of their interests, ought to be prioritized above or below them.
Business, unfortunately, exist to serve their owners. In most cases (I'm talking primarily about larger companies, not <5 people micro-businesses) the owners want money, so everyone at the company is there in order to get the owner more money. Happiness of anyone else, let alone the users, is entirely irrelevant, unless it happens to correlate with revenue. The only other universal incentive inside a company is self-preservstion, so besides doing whatever makes money, decision-makers will also take their own job security into account when making decisions.
Employees won't leave, because the company will make sure they're happy enough. It's surprisingly easy to keep people working for evil and/or faceless organisations if you pay them well, make them feel like part of a "community", etc. (see any FAANG office for an in-depth catalogue of these HR tricks)
I agree that this is "poisonous" and that such a company "shouldn't exist anymore", but this is how companies work in practice. This is not a sign of any kind of decline, but of a mature and healthy business that can keep going for decades. Execs change, products change, even owners change, but the business remains.
> This is simply not true. Business exist as legal constructs and there are many things that are good for the business but bad for almost everyone else.
It “exists” as an imaginary construct. The imagining of it exists.
Imaginary constructs have been hugely influential through history. Just think of the mythical figures in whatever religion you don’t believe in. People live and die for these figures. But the figures themselves don’t have any interests because only the belief in them exists, not the actual figures.
> Business, unfortunately, exist to serve their owners. In most cases (I'm talking primarily about larger companies, not <5 people micro-businesses) the owners want money, so everyone at the company is there in order to get the owner more money.
I sort of disagree here. From the worker’s point of view, the business exists to sign their paychecks. Why is this not just as valid as the owners’ point of view?
Realistically, lots of work-politics are driven by the interest of individuals to keep those paychecks coming in. For example, people will make it look like they are working harder than they actually are. Managers will inflate their headcount to appear more important. Etc etc. All of these things happen inside businesses, and if you look at the man-hours spent on them, I don’t think it is obvious that the interest of the owners is a bigger focus of energy. Particularly if we treat “the interest of the owners” as some distinct thing, separate from customer happiness or writing artful code. I think people don’t actually “think of the shareholders” much while doing their jobs, day-to-day. How else can we think of the priorities of a non-sentient thing, other than the aggregate priorities of its sentient, priority-having members?
> Employees won't leave, because the company will make sure they're happy enough. […]
> This is not a sign of any kind of decline, but of a mature and healthy business that can keep going for decades.
For these two points, in retrospect I was terribly vague to the point of just being either wrong or so open to misinterpretation as to be indistinguishable from wrong, so sorry for that. By “good people,” I meant people who were not interested in doing the things you listed. For “zombie state,” I meant shambling on profitably, but not doing anything interesting anymore. See IBM for most of our lives. I accept blame for this one! In particular, I regret writing “good people” because of course “good” is wildly open to interpretation.
> Execs change, products change, even owners change, but the business remains.
I mean, this is sort of a “business of Theseus.” It is really a matter of perspective if, having replaced every component, it is really the same business. Except, in this case, there isn’t even a physical ship in the end to point at.
—-
Also, it might be worth noting—the article is about what one ought to do, when weighing interests of different parties (user, dev, ops, “business”). If you disagree with me and think the business exists, maybe you agree that prioritizing it over users is not what we ought to do.
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.
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
IMO the reason the article had bring up this obscure !>< operator is because it treated this particular set of user interests as somehow separate from the users. The reason it is hard to rank business vs user interest is because business \in user.
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)
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 :)
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?
It's a priority ranking, not a zero-sum game.
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.
(dev = ops = user) ≹ (biz).
That's a pretty sad assumption.
"dev > user" is why a lot of projects have very poor usability.
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.
Or, we could ditch the "biz" part. It just so happens that software not written to serve business interests tends to also respect users.
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#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-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-fund...
[4]: https://blog.opencollective.com/funds-for-open-source/
[5]: https://docs.opencollective.com/help/financial-contributors/...
[6]: https://docs.github.com/en/sponsors/sponsoring-open-source-c...
The biz sits there rubbing its hands, watching us making the means of production more and more complex and expensive to use, so that it has a complete monopoly on creating software.
Devs are so used to relatively big paychecks from the biz that unconsciously tend to ignore these issues.
It’s not implementing dark patterns and cookie popups that makes you on the biz > * side. Tolerating the complexity of software development is. “Biz > complexity > *”. Push the complexity to the right as much as possible to ditch the biz.
Due to developer deformation it should be explicitly stated what the complexity is:
- Pointless “constant evolution” (version.major++ in less than 5-7 years, previous versions abandoned),
- Embracing epoch-breaking changes (2/3, ESM)
- Low-level as the norm (scaffold, config, listen, route, ddl, connect, hash, jwt, css, setstate, useeffect, fetch, … in place of business logic)
Also, I don't understand your last point. Are they all React builtins or something? If you're suggesting that the "shape" of an app's navigation, or of network or system calls, etc. should be how business logic is made concrete, I'd have to disagree. That sounds like microservices but with worse intrinsic documentation (the purest documentation there is).
Keywords in the last point are from all over the stack. They should be erased from code in favor of much simpler concepts. How you name the users table, which routes access it, should that be fetched or cached, how to structure code to display it — all that is not a businesses business. It should look like e.g. “root.current_user = await User.login(username, password)”. Everything else is low-level.
learning > biz > user > ops > maintainer > author
dev > *
learning > *
For example maybe you've spent 10 years building the same CRUD front-ends over and over. You're probably really good at that. And the companies that you worked for needed that skill. However, you'd be a lot more marketable if you had other skills that you could put to use at future jobs.
One of the worst examples was Amazon. They gave no indication ahead of time, but I was presented with a coding test with only a small subset of languages. My chosen language was F# because that's what I was most comfortable with but of course it was unsupported in their online tool. I solved a problem using discriminated unions, pattern matching, and pipelines. The interviewers were very confused, a bit antagonistic that I'd choose anything other than Java (even though no one told me ahead of time that there was a limited selection), and proceeded to show their lack of knowledge. For example, the interviewer kept bringing up a violation of the open-closed principle in my code. However, as I explained to them, that principle is only really applicable to object-oriented code. Since I was using a union data structure and pattern matching, that principle is not really applicable, as the functional approach is a transpose of sorts from the OOP approach. But I just got blank stares and an automatic deflation in the room of the interviewers communicating that they were ready for the interview to end. What was mind-blowing about it is that my resume lists nothing but functional oriented programming languages, with not a single example of Java, and I have plenty of code examples posted. But yet, I get asked some dumb question about reading a file using some terrible online coding platform.
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...
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 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.
https://www.askhaba.com.au/hairdresser-license-not-necessary...
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.
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.
> 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.
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.
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.
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.
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.
For anyone that didn't make it to the end, the conclusion was:
user > ops > dev
biz > ops > dev
biz ≹ userAt least that's how I interpret it.
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.
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.
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.
> 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.
Likewise code should be optimized for reading, which is to say for maintenance first, and for other things only if/when needed.
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.
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.
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-...
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.
I will accept this as a premise for the sake of argument, but it's certainly not a universal truth.
machine > maintainer > author > user
I'm always in the end of this chain, doing the dirty work :)
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.
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.
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.
I think SEO / Spammer share lots of that guilt. Not sure how to attribute them correctly.
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.
> 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.)
The full inequality seems to be:
biz > user > ops > maintainer > author
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.
So the corollary, in terms of concepts from my college programming languages class, is:
reliability > readability > writability
Nevertheless, article covered this context in the end as well.
> user > maintainer > author
This is completely wrong. To see why, replace the > signs with = and work backwards from there.
Isn't this vaporware?
Customer > User ??
A punch is a punch. Software is about getting used. (I swapped user with used, IME user can mean different things to different people)
Idealism > logic
So of course code should be readable over being runnable.
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.
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.