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.