alt Hacker NewsI couldn't disagree more with this description of why technical debt exists and it's a dangerous line of reasoning. Sure, maybe requirements weren't clarified. But often it's impossible to clarify them and you have to build something and even if the requirements were clear to begin with who is to say they'll still be the same by the time you've finished the project let alone 5 years later. Maybe the develop chose a stable and dependable technology because it's battle worn and proven? Maybe the sales person has to manage an impossible situation between an engineering team which can't commit to the time line needed to win the sale?
There are lots of good reasons tech debt exists, and it's worrying that this person seems to think that they all boil down to "I don't know how but someone, somewhere, fucked up"
Replies
The definition of technical debt is the compromises you intentionally make (generally to ship something thus not going bankrupt). Thus by definition nobody made a mistake: this was an intentional decision that was believed correct at the time. You will pay a cost later for the decision, but it is rarely a mistake to make those compromises.
It's worse, they seem to think tech debt is just a "state of mind", a "personality defect":
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
This line of thinking (we will make it with future change in mind!) is of course exactly the bullshit that is tech debt in the first place.
As someone else mentioned here: not all technical debt is created equal. I agree, sometimes the problem are changing requirements, etc. But it is also true that there is technical debt caused by developers who don't take the time to properly design features and will simply implement the first thing that came to their minds. I agree with the author, this kind of technical debt is caused by a mediocre attitude which often propagates to all the team if there is no one that calls it out.
The more interesting discussion to me is: how do you solve this problem once it exists in a team? I guess there are many approaches, but I tend to think that 'lead by the example' is the best you can do as an engineer, but a top-down approach might work better which is what happened at Microsoft when Satya Nadella became CEO.