I had a sobering realization the other day. Of all the companies that I have worked for over the years, the ones that had really solid engineering practices, the kind that made me proud, didn't make any money.
That doesn't mean that it's a general rule as I am sure there are plenty of exceptions, but it was still striking. In fact, I think I can say that the places that I have worked that were the most profitable were the ones where everybody agreed that the code base was an absolute mess.
Successful businesses can paper over bad code with money, because ultimately bad code just costs the business money.
A better way of thinking about this, I think, is that code quality expresses itself first and foremost in the product's long-term quality. And code quality, like all product quality, costs money.
But not all companies need good quality. Each business niche has a different quality level : product cost niche. A business will do best if the engineering quality matches the business needs, and vice versa.
A company that has spent money writing beautiful code that costs more to support than that business can generate, is in just as bad a place as a business that is growing massively and burning cash papering over a low-quality engineering department with all their new sales contract money.
Good code is basically investment in future velocity of the project.
And vice versa. But while "take a loan to get first version out of the door" is widely understood to be generally good decision, "invest into code so it can pay dividends later" appears to be some dark incantation nobody seems to understand...
Your table says code does not matter, but it does for consumer software. That's why Friendster failed and Google succeeded. Figma was made possible by WebAssembly. A lot of businesses had no "business" at the beginning; just a good product (and the code is part of that).
A quantitative way to say that is that rightsizing¹ your quality for your requirements maximizes the chances of success.
But code quality is much more flexible than business quality, so that large changes on code still have a smaller impact on success. What absolutely doesn't mean that code is irrelevant; it just means that marketing in incredibly important.
1 - What is a different word from "maximizing" for a reason.
Bad code can lose customers and eventually fail the business. I've seen it. The code was for paying customers and once the system was buggy enough, they left. All driven by clueless agressive management who read too many blogs about MVP etc.
How about "the companies with a very profitable business can afford to have a mess" and so they continue to have a mess because they are already surviving.
That doesn't mean that it's a general rule as I am sure there are plenty of exceptions, but it was still striking. In fact, I think I can say that the places that I have worked that were the most profitable were the ones where everybody agreed that the code base was an absolute mess.