Lately I have been kind of stumbling into a couple of issues related to technical debt, a bit more than I really wanted to so I guess it's time to write about this some things. Also, some ideas about this have been brewing in the back of my head for some time now so now is the moment to write all of it.
The first thing that comes in my mind when thinking about technical debt is how big is the area affected by it. In the best of circumstances it might affect just a specific area in an application, usually a specific feature because of bad implementation, unclear requirements, various disruptions, tight deadlines or many other reasons. This kind of technical debt usually doesn't have a wide ranging negative impact because it's local to a specific area. The only concerning case it when it affects a critical feature that it used often and updated often, even by other features.
On the next level, several areas of an application might be affected by some technical debt issue. This can happen if several features depend on some common functionality or if a feature was initially badly designed or structured, and when developers started working on newer features, they copied the bad structure of ideas from the old feature to the new features. Or in other circumstances, it may have been required to adjust and update several features at once, like improving them with some new technology but not properly using it or even using the wrong tool for those features. This is a more serious issue has it can affect developers quite often during the development process.
And finally, some technical debt can affect the entire application. These are the worst kind of issues. You can't develop anything for that application without running into it. Usually the root cause of these issues is bad design and architecture from the very conception of the application. These are the most challening issues to fix, sometimes it's actually easier to developed in parallel new areas of the application from stratch that trying to fix the existing issue, going as far as rewriting the existing features from scratch in new clean areas of the application.
Other than this, the actual impact of a technical debt issue can be quantified in various ways. The most harmless issues can impact negatively the development from time to time and usually they don't grow over time.
More serios issues can consistenly affect development in a bad way but without getting worse over time.
The most serious technical debt issues can have a snow ball effect. It can get worse and worse over time, even triggering new additional technical debt to surface. These are the worst kind of issues that need to be solved as soon as possible. Here is helps to have some experience to know where things are going, if they are going in a very bad direction to spot them and fix them as soon as possible.
Sometimes things might even evolve in time. Some issues might seem minor and not have serious side effects initially. They might even stay like that for a while but eventually they can get ugly pretty fast.
Again, it is important has a developer to see where things are going. This is one of the biggest differences between new developers and more seasoned developers.
In general, when technical debt issues occur together they actually have a much greater negative impact than if they occured separately. It's more like when you have multiple technical debt issues working together, their effect tends to be multiplied rather than being added up.
The last of this post is reserved to explain some basic ideas how to tackle and fix technical debt issues.
I see a lot of posts on the interned about magically fixing technical debt issues like there is an universal solution for everything. That couldn't be further from the truth, there is not one exact and specific solution for technical debt issues. There are an infinite number of possibilities here and usually each application has its own peculiarities.
A general approach would be to start fixing low hanging fruits. After they are fixed, other more complicated issues might become easier to fix. And so on. If you are lucky it might require a constant amount of effort and it might not become much harder to fix the remaining issues later on.
Or you may bundle normal development tasks with some refactoring and general improvements. This actually saves a lot of time and is very efficient. Firstly you already have a pretty good idea about what's happing in the area that you are working on. And secondly when you make unit tests or test some new changes, you test both the new functionalities and the things you cleaned up. It's actually one of my main guiding principles when developing software: always leave things cleaner after you work on something than they were before.
Having tests can also be a good thing but also a bad thing. If there are a lot of unit tests, a lot of times they may need to be restructured too along with the rest of the code. Or they may even become obsolete. Higher level tests are useful here like integration tests or end to end tests because they can end up not being changed that much or not changed at all.
But it doesn't always happen like this. Sometimes the only way left is the hard way, knowing all the ins and outs of the application and the business logic in a similar fashion to knowing the inputs and outputs of tests. You may even have to memorize the entire flow and logical diagram of the code.
In the end, technical debt is a complex issue that depends a lot on a case by case basis.
Comments
Post a Comment