To be a technical on my own, seems to me a lot of rush regarding (wrong) technical decision making originated from business side AND are not properly and efficiently offset on technical one. I am used to leverage port & adapter architecture where part of the game is to slow down technical decision until we really understand the context. This point is not clearly understood by the product management part as they are more interested in short-term (in term of delivery & sales) and as we do not find the winning way to communicate yet, thus the “technical uproar”. And to be honest it is difficult for many techs as well to be OK with the fact that we won’t “see” anything during weeks or months but the feeling that what we are working at matches the mental model (maybe because many techs do not take the time to understand the shared one or build their own)
Another issue is the assumption that making stuff the right way will always take more time. It is part of my daily fight as an architect. Doing ugly stuff is more costly at long-term but at short-one too. A bias occurs here as many compare the ugly dev with a “proper” one (design, dev, UT, CI/CD, …). Of course, this way the comparison is unfair, as they tend to ignore all the side effects (manual testing, regression, …). In the R&D world, D stands for Delivery not Development. That is the journey a lot of people do not achieve (yet).
Nowadays, it seems to me such a metaphor aka the debt does not fit anymore. If we stick to intellectual honesty, it seems reasonable to think that debt should be refund in a timely fashion. But is assumes as well as the debt is - or at least perceived as - redeemable. Sadly, we saw everyday big debt figures for states, companies, … that is more at the end of the day a plain old quantum rather than a first-class commitment. Debt analogy comes with the “too big to fail” mantra, and legacy code base are becoming the de-facto new “too big to curtail”.
As Mark stress out, we need a better ubiquitous language to promote it as a company challenge. We - technical people - have to surface the proper metaphor & metrics to ensure stakeholders will consider this as one of the main pillar to ensure company survival. For our customers. But for our employees as well. As for “real world”, I am pretty sure this onward rush model (the debt which is neither redeemable nor redeemed) is a short-term model that will sooner collapse. As for real world analogy, changing model is not for us but for coming generation. Current company stakeholders have to understand what is at stake and push for changes. Otherwise, those companies won’t survive.
