I completely agree. A thriving business with a poor quality codebase is the problem you want to have. Use the cash generated by business to pay developers to carefully refactor the offending parts of the codebase or architecture in a direction that reduces the specific business problems being caused by the poor code. Situation is not only sustainable but can be improved.
A business that is not thriving and running out of cash, with a high-quality codebase, is heading toward a terminal failure state. Situation is not sustainable with restricted options and time to recover.
> The other factor in code quality + business success is team size. With a big team and poor quality code, it spirals down much faster, each new bug/feature gets harder and slower to implement.
Slightly generalised, this a good rule of thumb for categorising different kinds of poor code and prioritising remediation efforts. Poor code that is stable that doesn't need to be modified and rarely needs to be read and understood by humans -- it's fine, no business impact, don't touch it. Poor code that causes production outages every week or that multiplies the time and cost of each new feature -- is causing an ongoing cost to business, can estimate business case of value in fixing it, worth prioritising for fix. Per your example, if the bad design is some architectural decision that impacts many developers or many teams each time any team makes a change: increased blast radius, proportionally larger drag on business.
A business that is not thriving and running out of cash, with a high-quality codebase, is heading toward a terminal failure state. Situation is not sustainable with restricted options and time to recover.
> The other factor in code quality + business success is team size. With a big team and poor quality code, it spirals down much faster, each new bug/feature gets harder and slower to implement.
Slightly generalised, this a good rule of thumb for categorising different kinds of poor code and prioritising remediation efforts. Poor code that is stable that doesn't need to be modified and rarely needs to be read and understood by humans -- it's fine, no business impact, don't touch it. Poor code that causes production outages every week or that multiplies the time and cost of each new feature -- is causing an ongoing cost to business, can estimate business case of value in fixing it, worth prioritising for fix. Per your example, if the bad design is some architectural decision that impacts many developers or many teams each time any team makes a change: increased blast radius, proportionally larger drag on business.