Thoughts that arose from Fadi Stephans session Managing technical debt in SCRUM Gathering Barcelona.
I believe that most of us have been in the situation where making a simple change to the system takes ages, breaks another part of the system, affects other functionality, breaks styles etc. These situations are one of the many symptoms that we have made technical debt.
Technical debt means that we have taken a short cut in coding, which will affect the development later on. Technical debt can be seen from many symptoms. These symptoms start to occur even before the customers or coders become unhappy. Viscosity gets higher, code becomes sticky, deployment is hard, compiling takes for ever, check in and check out is slow. Effectivity drops. Your team used to make a great amount of story points and bit by bit the amount of story points made in a sprint drops. The code becomes rigid and fragile. One change makes a cascading effect, it results in multiple faults or changes something else in somewhere else. Code becomes immobile. You will end up duplicating the code as you can not reuse existing parts of the code while they are surrounded by unwanted features which you can not strip off.
Technical debt comes from various reasons. To me the most of them is due to hurry. We are in a hurry to get new features introduced, we do not have time to refactor, we do not have time to design properly, we have no time to make unit tests and go on with a quick and dirty solution. Some other reasons might be misunderstanding of customers needs, poor skills or over architecting. Poor skills can be seen as a problem of young and unexperienced, but over architecting in my opinion is due to a long experience. You start to anticipate future changes or future features and try to make the architecture to match the yet unknown. This in most cases ends up in a situation where we have to carry an extra layer of code within. I have also seen situations where we have started the development of a small demo system and then it has evolved into large business critical application which still might have some demo features buried underneath. For the sake of honesty, I must admit, that I have also been the one to fall into the trap of saying, “ok, we can put the style sheet cleaning into the next version, ok, lets put the refactoring then into the sprint xxyyzz, is the reorganising of the language file really necessary in this phase” and so on. I am deeply ashamed and apologise all my dear developers, now I partly understand your pain.
Technical debt makes it hard, slow and expencive to make changes. I remember wondering many times how can one little change take so long. Customers wonder the same. When code becomes too complex and the technical debt is high, the changes are in worse case impossible, but at least costy. In the end the system becomes too expensive to maintain and nobody wants to touch it in the fear of braking something essential.
But there is hope. Do not surrender to a technical debt monster, it can be faught back. Be aware of your debt. Analyse your code. You can find out code complexity, duplicity, coding rules and amount of unit tests by using for example SONAR’s technical debt plugin. After you know your codes state you can start to make a plan to reduce the debt. Start registering your debt and how you are going to handle it and when. Make a technical debt backlog. You can choose to make technical debt removal sprints after release, use a rotating turn among developers to reduce the debt in each sprint or you can allocate 10% of the time in refactoring. This will all pay back. Your team will start to perform better as the coding becomes easier, quality gets better, deploying is easy and team is happier and can introduce new features fast. From now on, I will make an effort to do my share in the battle against technical debt.