Remember that everything has an opportunity cost. Running a lot of servers might cost $10 million annually, but if the product team had to choose between a project that would recoup $5 million of that vs. an opportunity to earn $50 million ARR for the same amount of work, the logical answer would be obvious.
Depends on how you measure your ROI and how it could be different from how your company measure their ROI.
The problem with optimizations is that you are competing in prioritization with other features. Reducing the baseline cost always has a limit of zero, while the upside from new features is infinite according to your leadership and investors, so it is very hard to argue against.
In general it's challenging to convince a non-tech crowd of the importance of addressing any tech debt unless you can demonstrate a tangible financial impact on the product, such as delayed contracts or customer churn.
You’re assuming performance has zero impact on customer retention, spending, etc which is demonstrably false. Further future costs aren’t bound by the current customer base or fiscal quarter.
Insufficiently optimized code kills companies in highly competitive markets.
“Reducing the baseline cost always has a limit of zero, while the upside from new features is infinite according to your leadership and investors, so it is very hard to argue against.”
> The problem with optimizations is that you are competing in prioritization with other features.
I think companies often over-indulge in features nobody wants, needs, or cares about. I quit my previous company because they were forcing us to build something that had single digit weekly active users. It was utterly pointless, driven entirely by some half baked navel gazing harebrained ideas about what a "nontechnical user" might want. But nobody ever asked any real users.
I estimate the company probably blew the greater part of $10M on this bullshit, not counting opportunity cost.
> In general it's challenging to convince a non-tech crowd of the importance of addressing any tech debt unless you can demonstrate a tangible financial impact on the product, such as delayed contracts or customer churn.
People like that are problematic not just because they don't understand tech debt. They also don't understand products. There are shitloads of people in the industry who market themselves as some kind of mystical gurus, are able to deliver impressive monologues talking over everyone on the zoom call, but contribute nothing else than a sense of urgency and frustration. If you find yourself in their company, better to just leave.
> People like that are problematic not just because they don't understand tech debt. They also don't understand products. There are shitloads of people in the industry who market themselves as some kind of mystical gurus, are able to deliver impressive monologues talking over everyone on the zoom call, but contribute nothing else than a sense of urgency and frustration.
I can easily picture both tech and non-tech individuals acting this way; in the end egocentric people and employees with a herd mentality exist in both groups. I'm old enough to have participated in several major version rewrites aimed at resolving performance and technical problems. More often than I care to admit, these projects failed, often after several delays, and didn't show any real improvement over the existing system, apart from hopeful conversations about the future and tech presentations at local conferences.
I agree rewrites are generally not productive unless the original system is so far gone that it makes sense to start over.. but that's actually very rare.
The thing I think is absolutely ridiculous is when organizations can't figure out how to get work done which improves the performance (cost, efficiency, speed, etc) of their existing features. "Prove to me it has {financial, customer, etc} impact" is just how managers who care about nothing other than rolling out new features prevent the work from being done. It makes sense, they get promoted when their underlings deliver some splashy new thing. But it's an incredibly stupid way to build software. If the thing was worth building in the first place, surely it's worth making it good, right?
