Processes, tools, and diligence vigilantly seem the most apparent path. Perhaps rehash the 50 year old debate of professionalization while AI vibes coding is barking at the door, because what could possibly go wrong with even less experience doing the same thing and expecting a different result.
I don't think we'll reach this promised land™ until incentives re-align. Treating software as an assembly line was obviously The Wrong Thing judging by the results - problem is how can we ever move to a model that rewards quality perhaps similar to (book) authors and royalties?
Owner-operator SaaS is about as close as you can get but limits you to web and web-adjacent.
Get couple shredded guys and gals to show off how fit they are so everyone feels guilty they are snacking past 8PM.
Sell another batch of “how to do pushups” followed by “how to do pushups vol.2” with “pushup pro this time even better”.
Where in the end normal people are not getting paid for getting shredded, they get paid for doing their stuff.
I just constantly feel like I am not a proper dev because I mostly skip unit tests - but on the other hand I built last 15 years couple of systems that worked and were bringing in value.
However, you should want to build quality software because building quality things is fulfilling. Unfortunately certain systems have made the worship of money the end all be all of human experience.
Obviously, this assumes you write enterprise grade code. YMMV
(The answer btw: Because nobody would be able to explain to a jury/judge that 80% or whatever is enough)
But still cottage industry of "clean code" is pushing me into self doubts and shame.
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.
The whole ballgame is making sure you have no low quality people on your team.
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.
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.
Key word is ‘can’. And it takes far more time and money to assemble “quality” 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.
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.
I think it’s like switching CEOs when the company goes out of startup mode into grownup company. What got you here won’t keep you here.
I’ve converted people by building better systems than they’ve seen before. Some balk, but better than half end up getting it and pitching in.
which is now claude code...
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.
Everybody who worked with the 2005 Toyota Camry ETCS would have known what was up when it killed a few people, for example. Nobody can work on spaghetti code of that magnitude and not realize that something is off.
Boeing employees who tried to blow the whistle were similarly ignored or silenced while a few died in mysterious circumstances.
Maintenance programming is for chuds. Winners leave unmaintainable piles of spaghetti for the next poor soul to untangle. AI will only further encourage this way of developing software as the source code becomes next to worthless and people start writing software simply by praying to the LLM in English, hoping the genie in the cloud is able to divine their intent correctly. Cyclomatic complexity, coupling, cohesion, SOLID, and "clean code" are obsolete and useless knowledge under this paradigm, because the code no longer needs to be intelligible to and maintainable by humans in a world where it's the LLM interfacing with and manipulating the source.
After all, if the old codebase starts to collapse under the weight of its own design, you can just get the AI to spin up a parallel implementation at feature parity within a week.
If you're working at a company who disregards safety and security good luck getting them to care about clean code and efficiency.