When does technical debt kick in

In the past couple of years, I went through a lot of discussion about best practices, standards, architecture etc. All the clean code arguments with people saying it is ok to have more than 300 lines of code in a file or why do we need to create small reusable functions which do 1 thing and have only one responsibility :)

I came to a discovery while preparing a presentation about domain driven design which made me realise why are some people so much against best practices, coding standards and why they just can’t write clean code and why is it such a pain to argue with them.

This chart shows the benefits of DDD for our concrete project in a long term perspective but there is 1 other thing worth noticing. The dashed red line at 6 months is the approximate time needed for technical debt to influence your project. That is the time when your delivery drops and even the simplest of features takes incredible amount of time to implement and introduces a lot of new bugs, especially when your system is tightly coupled.

Translated into human language, it is very hard to convince people who have experience only with small projects and never worked in something long term about the importance of standards, architecture, clean code etc. People who worked on small websites just lack the experience, because if you work on projects under 6 months, you don’t really need to care about any of it..you can easily get away with any spaghetti you put together :)

I feel this discovery can be very useful for everyone working with junior developers, people with less experience and when trying to explain why we need to introduce a new linting rule.

Hope you like the chart, looking forward for your feedback :)