Why Technical Debt Sucks

And I do mean sucks.  Technical Debt sucks at our energy, motivation and velocity. 

Technical Debt is a term that composes Defects, Shortcuts, Workarounds and other contributors to sub-par quality software.  Shortcuts in this case refer to intentionally writing code that quickly solves a problem.  While the problem itself is fixed, on average a shortcut also becomes a primary contributor to side-effects. 

Defects are something with which we are all familiar.  Carrying defects across sprints kills velocity.  I had to announce to our stakeholders today that, while our team has averaged 30 story points over the last 6 sprints we were only able to complete 14 story points this past sprint because we had 8 defects to fix some of which had a lifespan of a year.  There is nothing that should be more embarrassing to a team than to have to explain this. 

Short answer, run a sprint bug free. 

Unit Testing is not Important, It's Critical

I recall reading a paragraph in Kent Beck's book on Test Driven Development Test Driven Development: By Example in which he points out that developers end up writing almost twice as much as they would have written had they not used TDD to drive out the design.  This is most likely in the top 5 reasons why many teams and companies don't adopt TDD as a standard practice (aside from the paradigm shift TDD entails) although what isn't obvious is that the first releasable version of the code will most likely consist of far fewer lines of source code. 

There is a similar albatross hanging around the neck of teams who want to shore up QA efforts by writing unit tests.  In many eyes outside of the immediate team, it is simply perceived as writing more code than is necessary to solve the problem.  This mindset cannot be further from the truth.  As more and more companies start to adopt iterative approaches to software development, having developers write tests that exercise their code during the iterations is mission critical.  The manner in which code is written iteratively requires that top-down or bottom-up approaches to development be turned on their side.  Rather than fully completing the data access layer, iterative approaches require that UI, Business and Data Access all be written for a small vertical sliver of functionality.  This approach ultimately means that all layers are affected with each new feature.  Equally, the baseline architecture may also be affected with each new iteration. 

The end result is source code that is constantly in flux as it is being re-factored to add new functionality.  To battle this flux, we turn to unit tests.  If you are new to unit testing, think of it as non-visual code that executes the non-visual portions of the application.  Ultimately, this means that QA resources (which tend to be a scarce resource) need to focus only on exercising the application in the guise of the end user.  With unit tests shoring up their efforts, QA can do black box testing and ensure that the visual aspects of the system behave correctly.  Additionally, developers can be fairly certain that when a defect is found it is contained within a much smaller boundary (typically infrastructure for complex systems or maybe just in the integration between the visual layer and business layer). 

Iterative development does not have room for monumental efforts at the end of a release where thousands of bugs accumulated over each iteration are then resolved.  Defects need to be resolved as soon as they are discovered and the end goal needs to be discovering and resolving them DURING the iteration, not in some future iteration where the central focus is finding them. 

If there remains a doubt in your mind, contact me and I will make myself available online for a demonstration of just how effective unit testing can be in managing defects.