Paying technical debt vs adding business value.
If you don't care about technical debt, read this to understand how it impacts indirectly your business.
I can’t add business value in an environment filled with technical debt as fast as in a clean environment.
The higher the technical debt, the exponentially higher the cost of adding business value.
An example
Project starts well, developers are delivering good amount of features without caring much. Technical debt starts to rise.
After 6 months, developers are starting to deliver less, always talking about difficulties integrating their new work.
After 12 months, barely any feature comes through, and developers are explaining it’s because of the technical debt and rushed design choices made to ship more features at the time.
Thus, doing things properly gives you the advantage in the long run.
Now the counterintuitive thing:
Taking 5 minutes around a cup of coffee to brainstorm about the best way to implement this isn’t going to slow down the project.
Taking the 30 seconds it requires to format code and review warnings isn’t going to slow down the project.
Taking the 17 seconds it needs to change that-variable-name-that-was-unclear when you browsed the code isn’t going to slow down the project.
On the contrary, it keeps the team sharp and motivated, and the code clean.
Thus, Doing things properly gives you the advantage ALSO in the short run.
In conclusion
I love the idea that the code is a cost. Each line has a cost. The simpler to maintain and make evolve the code is, the less expensive it is.
Fixing the technical debt is a value-adding activity, because it reduces the cost of the code.
I once have worked in an environment where it took me more than two weeks to do what I could do in one day in another environment. The main difference was a codebase so messed up, I had to draw huge diagrams to find where the data was flowing. I believe those diagrams are still used there.