Thank you for this great article.
Your thoughts on technical debt pretty much reflect the lousy situation that i'm experiencing right now.
The project itself has deadlines from hell. This is because the executives want to satisfy the customer
with no regard for anything. In such situations you are always working on the limit especially if the team
isn't that large. So you are making compromises on tasks that will lead to shippable software (hopefully)
with a total mess under the hood.
So here is the bad news:
You know that the software is badly written at several points but the next features need to get implemented
to satisfy the customer "one more time". Hence you can't do anything about the critical state of the software.
Instead you're building something on top of an unstable construct - what could go wrong :-/
After several iterations of this process you will come to a point where you can't implement anything without
breaking the whole thing at another part you weren't aware of.
The amount of time that is needed to "repair" this huge clusterfuck your project has become could be
pretty huge. In some situations you are better off hitting the delete button and throw it all directly into the
But if one decides to tackle the task and do a massive refactoring you are loosing time. For sure the customer won't understand why you are not able to put all his requested features into the next version anymore.
Consequently there is a chance you are loosing the customer in the worst case.
Conclusion (based on my personal experience):
Never let the technical debt exceed a specific limit (depends on the size of the project, team size and several
other factors). Otherwise you will pay the price - and it will be expensive!
I would love to read more articles from you :)
Until then i wish you all the best with your project and your family.