I believe we should stop using the phrase technical debt
when we talk about properly architecting something very complex AND complicated to avoid technical debt
from creeping in.
It gives the client (the business) the wrong idea of why we're doing something, and the consequences of ignoring.
I know there are solid reasons why over-engineering can be just as big a risk to business as no-engineering (*LEEROW BROWN!) ... hence my post to prompt a discussion about avoiding technical debt
.
Many businesses's consider addressing technical debt, as gold plating the engineering
, and while, they agree it makes it better, from their perspective the money (and time) is not well spent; it delays time to market and delays product and feature feedback resulting in bad quality and bad engineering. So, I get it.
However ...
When you design something complex AND complicated, there are corners that an experienced Architect knows you cannot cut. Cutting the wrong corners on a COMPLEX AND A COMPLICATED project is almost always guaranteed to be a predictably fatal disaster, often with no room to recover from.
Some engineering is done to incrementally (compounded benefits) improve code over time, and conversely, the lack of that work, is quite rightly technical debt
. But other up front design engineering/architecting is done to save lives and projects, ... it can be literally that critical.
Some decisions cannot be refactored out later. (clean up the technical debt). Like, where are you going to build your town?
I'm wondering what phrase we should start using instead ... so that our clients can make more meaningful and informed decisions and understand the differences?
hashtag #technicalDebt
Leeroy brown : geek joke! aplogies if this is cryptic
(This post moved from Linkedin to my blog)