Eleven years ago I co-organized the first Workshop On Technical Debt with Steve Poling; Michael Kelly was our facilitator. Since that time I published a cover story for Better Software Magazine on the topic and continued to work in the field. It is common for me to perform consulting and contract assignments and hear the term. Sometimes management listens; sometimes they don’t. Programmers might slag on the work done by the previous programmers. Sometimes the programmers are talking about their own work.
In all that time, I have noticed something startling.
Whenever people are talking about “technical debt”, there is invariably a programming skill issue involved.
Skills to Clean As You Go
Here’s a simple idea for you.
First, have a continuous integration server.
Second, measure statement coverage of unit tests and complexity of the code.
Third, insist that every check-in instead coverage and decrease complexity. That statement might weaken when the code reaches an advanced state. There might be exceptions for good reason. Still, for most companies current state, i’d expect things to get a little better for some time.
Bring the ingredients to a boil, stir and simmer.
Just doing that solves about half the technical debt problem.
Why don’t companies do it?
They don’t know how.
Even if they set up the measurements, the programmers likely don’t have the skills to improve the measures. They may complain the code is a “mess” or “Spagetti”, but they don’t know to make the fix. At least, not a code-as-you-go, clean up a bit at a time, boy scout fix. The code will have too many inter-dependencies. The objects will rely on each other. The programmers will not be able to take one piece out and write a unit test. Without unit tests, they will not have the confidence to refactor.
Instead the programmers will suggest “technical stories.” These technical stories are essentially rewrites.
Technical Debt Stories
A technical story to upgrade an operating system or a database version is one thing. What I am writing about above are essentially rewrites.In some cases, they might be justified – replacing some custom code with a message queue, for example.
Yet a great deal of the “ugly code” is due to bug fixes. When the big rewrite produces “clean” code, it likely produces and entirely new set of bugs. There are ways to deal with this. My company, Excelon Development, recently wrapped up a project to create a random test generator. With that test generator in pace we could send input to both the old system and the rewrite and compare results. Short of that rewrite, the best option is usually a”shake down cruise” of human testing that finds bugs. Without skill, the fixes for those bugs will create ugly code.
In two years you get another legacy system people want to rewrite.
The solution is skill.
Advanced Programming Skill
One of the highlights of my career was contributing as a reviewer to Robert Martin’s Clean Code. My name isn’t on the cover, my effective hourly rate was probably under minimum wage. It have a few nits with a few sections, but overall, it’s a good book. The book gives the reader tools to make better code. Code that is built out of modules that are clear, clean, and testable.
Learning to write good code is a skill. It takes practice. Reading the book is not enough.
It reminds me of part of Zen and the Art of Motorcycle Maintenance. In that book, the hero instructs an English class. He has them rank-order the papers in order of goodness, from best to worst. Once they see what “good” looks like they can improve their work to move in that direction.
Most programmers don’t know how to keep code “good” in the face of change.
They see a mess. They want to rewrite it.
What they don’t know is to prevent the next piece of code from being a mess.
If you are facing that, here is my suggestion.
Set up CI anyway. Measure coverage and complexity anyway. Give them tools, give them training, give them a little time. Simmer and stir.
You might be surprised at what you can cook up.