It doesn't happen because building the best software is not the goal of a software engineering job.
If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-even point is usually at a lower level of quality than engineers would like it to be. Leadership and engineering managers know this and behave accordingly.
This is only true in certain contexts. Most of the time software quality is looked over not because it genuinely isnt important but simply because it's hard to perceive.
Ive watched many businesses appreciate the benefits of software quality (happy customers, few incidents, fast feature turnaround) without ascribing it to anything in particular.
Then, when it went away, they chalked up the problems to something else, throwing fixes at it which didnt work.
At no point in time did they accurately perceive what they had or what they lost, even at the point of bankruptcy.
Part of the problem is that the absence of bugs, incidents and delays just feels normal and part of the problem is most people are really bad at detecting second order effects and applying second order fixes. E.g. they think "another developer will fix it" or "devs just need to dedicate more time to manual QA".
Conversely, because it's so hard to see I think it can make a really good competitive moat.
We are getting to the point where people don’t even do the “make it right” part of Make it Work, Make it Right, Make it Fast. It’s making it tough to push for the latter when you can’t even get Right out of some people.
Why make it right if I have an easier life and get paid more if I don’t?
In this industry the only thing that matters is money and people have adjusted accordingly.
Ouch. It seems that when a manager sinks some team's velocity by adding a bad developer to it the following reaction is always to add more bad developers so the velocity recovers.
And then when they can't herd all the bad developers around, the obvious next step is to finish destroying everything again by imposing some strict process.
The argument here isn't "the goal of a software engineering job isn't economic", it's "sometimes quality is aligned with economic goals" (which is of course true).
If there's a 10-point scale from 0 = the most hacked-together nonsense and 10 = perfect formal proof of correctness, I'm arguing that a lot of engineers should come down from a 9 to a 6, not to a 0 (or at least, that they'd benefit from picking their battles about when to argue for a 9).
In business contexts, I often argue the opposite, trying to move them from a 3 to a 6, because nontechnical people often underestimate the importance of tech debt. That's not a typical problem on HN, though.
While I agree with everything you've said, I think you might be making an assumption that quality costs time. In my experience this isn't the case, unless you're starting from a low quality codebase or working with low quality people. A high quality team can produce high quality software in less time than it takes a low quality team to produce low quality software meeting the same functional requirements.
The whole ballgame is making sure you have no low quality people on your team.
The quality of your team is more-or-less a pre-existing background variable. The question is whether a team of comparable quality takes longer to produce quality software than hacked-together software, and the answer appears to be "yes". The only way out of this is if optimizing more for code quality *actually helps you recruit better engineers*.
I can put a little data to that question, at least. I run a recruiting company that does interviews, so we have data both on preferences and on apparent skill level.
I went and split our data set by whether an engineer indicated that emphasis on code quality was important to them. Our data suggests that you can probably make slightly better hires (in a raw technical-ability sense) by appealing to that candidate pool:
- Candidates who emphasized quality were slightly (non-significantly) more likely to pass our interview and,
- Candidates who emphasized quality were slightly (non-significantly) less likely to have gotten a job already
The effect is pretty small, though, and I doubt it outweighs the additional cost.
> A high quality team can produce high quality software in less time than it takes a low quality team to produce low quality software meeting the same functional requirements.
Key word is ‘can’. And it takes far more time and money to assemble “quality” team.
Companies can sacrifice every thing for "time to market" - optimization, maintainability, security and safety even - but underestimate the costs of doing that. It is actually more a marketing choice than an economic choice.
One can be skeptical about the implied statement and leadership/management knows what it is doing beyond delivering at the (arbitrarily) set time. One definition of Quality is to satisfy a need entirely at the lowest cost in the shortest time, but more often that not, the last term gets 90% of the attention.
Do they? I’ve been fighting against the tide for years until I understood that all of quality this and quality that doesn’t matter. Sure, it sucks to be on the receiving end of buggy software, but this where you vote with your money. At work? Finish the task with least amount of resources and move on.
It’s about momentum. Once you lose it the wheels come off. And at first that’s shipping product, but later on it’s adding new features to the minefield you’ve laid. Until you start clearing the mines your velocity continues to drop.
> Until you start clearing the mines your velocity continues to drop.
I've been doing this for decades, it's never a problem. Either velocity tanks in which case there's a short period where company invests into improving it, or people leave.
I've seen projects that failed, or were killed, likely at least in part due to a culture that encouraged poor quality and tech debt. This is preventable, and for no additional up-front engineering effort or time investment.
I think this is the most common failure mode I’ve seen, short of a failure to find a proper product-market fit.
It’s just really hard to overstate how much damage a bunch of crappy code can have. Even with the best of intentions. I must say I strongly disagree that this is “never a problem”.
One of my managers was fond of the phrase, “a project is done when nobody is willing to work on it anymore.” That can be because of a number of reasons, including that the money is gone, or it sucks your will to live.
Yes, parent says "people leave" as if it is not a problem in itself; you lose the time it takes to train these people, and they probably take some knowledge about the products with them. Or maybe we are actually talking about commodity developers?
But I'm curious about how one prevents this dysfunctional culture.
You said that right! Absolutely. It's one thing to fix a mess in a culture that cares. It's darn near impossible to fix it if the culture around is hostile, indifferent, or any of the other 82 million other reasons organizations come up with to not care. In that situation you can end up being the pariah despite good intentions engineering and otherwise like satisfied customers.
> Companies can sacrifice every thing for "time to market" - optimization, maintainability, security and safety even - but underestimate the costs of doing that
If you're working at a company who disregards safety and security good luck getting them to care about clean code and efficiency.
Few people who advocate for software quality want better software just because it's more aesthetically pleasing.
Often, we've worked on codebases that were nearly collapsing under their own weight, where adding even small features would take an inordinate amount of time, where most changes would have unintended consequences, where onboarding was incredibly hard, etc. And we've worked on other codebases where changing things was easy, so we know the difference.
Often, the business has no clue how to fix this because a) they're non-technical, b) we unfortunately have no consensus in the industry about what "good code" is, c) humans are much better at short-term than long-term thinking.
> It doesn't happen because building the best software is not the goal of a software engineering job.
You made a reductive, declarative, omniscient value judgement that is patently false. Managers just want to have the right buzzwords, the biggest budgets, and the coolest projects. (We won't point out that they have pointy hair.)
As LLMs lower the cost of creating software, shouldn’t that change this equation? Perhaps we can be focusing on creating well done optimizations now to give more data to LLMs to have them do future optimizations on other projects. Of course you’d still eventually hit a lower bound on any returns at all, but it will be way lower than the pre-LLM era
If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-even point is usually at a lower level of quality than engineers would like it to be. Leadership and engineering managers know this and behave accordingly.