6 ms·

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

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.

jcgrillo 1y ago
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.
- deleted 1y ago
  [deleted]
- wiseowise 1y ago
  > 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.
- rachofsunshine 1y ago
  This isn't an apples-to-apples comparison. 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.
pydry 1y ago
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.
- fuzzfactor 1y ago
  >At no point in time did they accurately perceive what they had or what they lost, even at the point of bankruptcy. This is traditionally not only with software, but other kinds of companies too. Some people are just not quality people. At this conference there's a presentation encouraging "You should finish your software." If that's all people did that would be 10x better right there.
  - hinkley 1y ago
    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.
    - portaouflop 1y ago
      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.
- hinkley 1y ago
astrobe_ 1y ago
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.
- wiseowise 1y ago
  > but underestimate the costs of doing that 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.
  - hinkley 1y ago
    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.
    - wiseowise 1y ago
      > 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.
      - rizzom5000 1y ago
        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.
scrubs 1y ago
The more systems it is (distributed databases, leader election, strong serialization, safety critical) the more so cheapest path looses. Making a bug fix on jira or web page there's less to loose.
Tainnor 1y ago
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.
clayhacks 1y ago
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
burnt-resistor 1y ago
> 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.)

jcgrillo 1y ago

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.

deleted 1y ago
[deleted]
wiseowise 1y ago
> 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.
rachofsunshine 1y ago
This isn't an apples-to-apples comparison. 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.

pydry 1y ago

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.

fuzzfactor 1y ago
>At no point in time did they accurately perceive what they had or what they lost, even at the point of bankruptcy. This is traditionally not only with software, but other kinds of companies too. Some people are just not quality people. At this conference there's a presentation encouraging "You should finish your software." If that's all people did that would be 10x better right there.
- hinkley 1y ago
  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.
  - portaouflop 1y ago
    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.
hinkley 1y ago

astrobe_ 1y ago

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.

wiseowise 1y ago
> but underestimate the costs of doing that 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.
- hinkley 1y ago
  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.
  - wiseowise 1y ago
    > 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.
    - rizzom5000 1y ago
      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.

scrubs 1y ago

The more systems it is (distributed databases, leader election, strong serialization, safety critical) the more so cheapest path looses. Making a bug fix on jira or web page there's less to loose.

Tainnor 1y ago

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.

clayhacks 1y ago

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

burnt-resistor 1y ago

> 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.)