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?