Code is the problem

At the Norwegian Smidig conference this year Dag Sjøberg held an interesting lightning talk (in norwegian): Viktigste faktorer for å redusere teknisk gjeld. Dag presented findings from an experiment into the effects of technical debt. After submitting tenders, 4 software houses had been asked to actually build the same system. These 4 systems were then put into production. Users were then randomly assigned to one of these systems each time they logged in. After a couple of years an independent expert was asked to review the code in each system and assess its maintainability. Finally, the same changes were implemented in all of the systems.

So, what were the results from this small experiment? It turns out that the expert was not that good at predicting which system would be easiest to maintain. Another surprising fact was that the level of technical debt in a system was also a poor predictor of maintainability. There was only one aspect than correlated very closely with the time spent implementing the changes: the amount of code in a system. The system with the smallest codebase required the least amount of time to implement the changes despite the fact that it was not very well written.

Now, you may object that a sample size of 4 and 1 maintenance iteration hardly makes for a scientific study. Unfortunately, this is about as good as it gets in computer “science”. This study does not prove that technical debt is irrelevant or that the size of the codebase is the only thing you should care about. Use the results with caution. For me, this study is one of many things that point towards an inverse relationship between the size of a system and its maintainability. The concept of competence debt is closely tied to the size of a system.

If the size of a system is important the question becomes: how do you keep it as small as possible while still being able to provide a lot of value? The answer is as obvious as it is sublime. The code should be succinct and a system should only do what it must be able to do. The hard part is achieving these goals… a post about that will follow

Niklas Björnerstedt

Note
One obvious point I forgot to mention when this was posted is that refactoring out technical debt leads to a smaller codebase. So even if it did turn out to be the case that code quality never has an impact on maintainability the reduction in amount of code should have an impact.

Posted on 2013.11.22 at 13:57

Comments are off for this post.