This is an interesting explanation for why software managers have a tendency to undervalue software architecture quality. In most areas of life, better quality simply means more expense for an object that otherwise serves the same functional purpose. So, with software architecture, so instead of spending money on improving the quality, you can instead use a cheaper architecture that will save you money that you can spend on more features, right? Wrong. Worse architecture quality slows down the rate that new features can be added, so actually the payoff doesn’t justify itself, except over the very very short term.
20190125/https://martinfowler.com/bliki/TradableQualityHypothesis.html
In other words, this oft-repeated internal dialog and capstone phrase I think to myself in regard to DSLR camera technology also applies equally well to the discussion of software architecture.
“It pays because it’s cheaper.”
“It’s cheaper? Cheaper not better.”
The point here is quite obvious to DSLR affectionados. You might think you’re saving money in the short term when you buy cheaper equipment, but pretty soon, you’ll realize that you’re working slower using the cheaper, lower-quality equipment, and in addition to the fact that it keeps breaking down and you have to keep buying new cheaper replacements, pretty soon you realized you would have saved a lot of time and money by buying the higher-quality, more expensive equipment.
Alas, despite the obviousness of this explanation and analogy with (D)SLR camera equipment, somehow this is something that most software managers don’t understand, probably because in today’s world, most software managers (and therefore software developers) work inside the consumer technology sector. Seriously, what other consumer technology can you escribe the “cheaper not better” rhetoric to? Software is the lone wolf in this regard.