How much does zero technical debt cost?

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.

The program has started

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.

 

When is the best time to report on technical debt?

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.

How to handle on-boarding new staff when running a zero technical debt program

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.

  1. Don’t submit your code if you see yellow static code violation warnings.
  2. Make sure your coverage analyzer shows green.
  3. 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.

Starting a new zero-technical debt program

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?

An update to the Quality Feedback TSS PostIs

Aside

An update to the Quality Feedback TSS Post

Is it possible to have an ordinary team of developers commit code with no technical debt?  It is definitely possible to manage the process so that the debt is continually paid off.  No debt remains outstanding for more than a few months at most.

I published this on TheServerSide almost 3 years ago as Build a Quality Feedback Loop Using Sonar.  As an update, the team of 100 developers has increased its code code coverage in 3 years from 30% to 80% (both line and branch) without slowing down business development.  The number of tests has increased from 2,000 to about 37,000 now.

 

The number of business defects in an application tracks with the number of technical defects.  More technical defects normally means more business defects.  This means that technical defects can be used as a metric for the overall quality of a development approach.  Sonar is a great dashboard for tracking code quality at the project and file level.  But how can it be used to as part of the daily workflow? With a little work, key  feedback metrics can be integrated into the code/test/commit/build cycle at the individual level.  Code quality becomes visible to individual developers providing immediate feedback.

Implement a Zero-Defect Enhancement Process.  Integrating Sonar metrics into the build cycle enables the automation of a zero-defect code quality policy.  Use the metrics to inform developers immediately of a quality regression.  Every submission can be monitored so that developers can quickly correct and resubmit the corrected code.  Code quality increases as a by-product of the enhancement process.  Code correction early in the project reduces the number of large re-factoring projects leaving more resources for projects that automate the business.  Code quality is automatically enhanced as a part of the normal development process.  A system with active enhancements can realize a 15% to 25% annual increase in quality just by baking quality into the build cycle.

Code Quality Czar.  As with any quality program, management support is crucial.  Like all metrics and quality measurement and management programs there is some overhead.  A typical rule of thumb allows 1% extra overhead to measure productivity and quality.  In this case, management must have an experienced Java developer or developers available to answer and resolve developers’ inevitable code quality issues and questions.