A question I’m often asked is how much extra does it cost to operate with no debt? What’s usually meant by this is how much extra effort is required to have 100% unit test branch and line coverage. There’s the effort involved with managing the extra code that’s involved in unit tests. About 35% of the commit activity is for unit tests on a 2 million LOC project with 37,000 unit tests. There’s effort in maintaining the tests and re-factoring the tests or changing them if an API changes. Sometimes the tests are brittle or change global static causing an unrelated test to mysteriously fail. So there’s work involved.
Studies at 3 major companies show that the extra effort is around 20%. This is the amount show by all three, independently of each other. So that’s the number I use. It jives with my own experience as well.
Of course, one can always say the the extra testing costs nothing because you recover the testing cost by defect reduction. True enough but most project managers are responsible to estimate specific tasks and projects which don’t usually include (or track) defect remediation. They need to estimate code and test effort. So it’s fair to consider the testing burden.
Today we started the program. 17 developers received notices of technical debt for yesterday and 22 for debt incurred today. However no response from any but it may be that they don’t know what to do about the emails yet. That will be presented to their managers next week.
The closer code comes to shipping, the more tech debt should be reported in a targeted manner.
Today a new release was cut along with new technical debt that was branched with it.
Shipped code is a natural time to take stock of recent technical debt. Why? Because debt should be minimized and shipped code with debt should also be minimized.
By reporting debt to the class, metric and developer level the debt was made actionable and visible. Such tech debt reports were always available during the sprint but often take back burner to seemingly more pressing development, But the targeted reporting by leads and reviewers to management started 9 days earlier. At that point 33 developers had debt. By the time of the branch, the targeted reporting had nearly halved that to 18.
I was asked to explain to a group of managers why their project’s technical debt rate was degrading. It was starting to pile up right before the release was to be cut. There’s supposed to be no debt branched into a release.
I looked at the recent technical debt sorted by developers and their debt and I noticed that most of the large debtors were the new staff, who were otherwise good consultants. Why would new staff create so much technical debt?
First, they are being evaluated for what they produce. Does it meet the business function and the promised date? Second, no one is coaching them on writing quality code because they met their dates. Code quality is often tomorrow’s problem, not today’s.
It’s really fairly simple.
- Don’t submit your code if you see yellow static code violation warnings.
- Make sure your coverage analyzer shows green.
- Put asserts in your tests.
Coach that new person in these 3 simple steps. Make sure they do it on the first assignment and ask them to follow those steps on subsequent ones.
Test-driven development may not be for everyone. But I always stress that you can use the “code a little, test a little” approach. Write a little code, write a unit test. Reason about the code for a minute. What if I pass a null to the method? What would happen? Don’t know, write a test. Null tests are the easiest to write. Even if it results in a NullPointerException, save that test. It’s the “don’t throw out your garbage” principle. Then, after reasoning, put a JSR305 annotation on the argument that it must be Nonnull and say why.
Zero technical debt just takes a steady, day in day out, approach to quality. No drama, just a steady focus by all concerned, leads, managers and developers alike.
Well, it’s time to start up a zero-technical debt program on a new project. This time it will be C# and .Net so we’ll see if the same process can work in that environment. First we have to develop the technical debt policy.
- How much debt should the developer carry and when should they pay it back?
- What do we set the defect metrics to? In particular what about the complexity metrics? High complexity correlates to run-time defects.
- Who is responsible and accountable for the debt? The submitter, the lead, the project owner?
- How often do we notify? After each build?
- Should we track contributions, too? Should those metrics be just informational or motivational? What’s the culture?
- What is the role of the code reviewer? Will they review the tests? Do they coach?