"It's all about Version 2.0"

Andrew - don't take shortcuts, they don't payoff in the long run and often not in the short run either. That is what Dave Stanton, my CTO when I was at Sage IT Partners, was conveying when he said that good software development "is all about Version 2.0".

We have a phrase in my business for taking shortcuts. We call it technical debt. A software development project goes into technical debt by borrowing time by not allowing for quality work today in hopes of getting more functionality completed for the impending release. But we eventually will be forced to pay back the time, the technical debt, if the project makes it into production (and therefore into maintenance mode) or if the business chooses to invest in a Version 2 of the application. There is no getting around it. We either have to take the time to fix the stuff that has been done hastily in Version 1 or we will struggle with modifications to the application because of a fragile code base. Each takes time. This will result in either fewer features in the next release or a delay in releasing Version 2. Payback is a bit...oops, sorry, I'm your dad and I shouldn't talk like that in front of you.

I think we (IT Project Managers) have done a poor job of communicating the concept of technical debt to our business sponsors. We continue to get asked to accelerate schedules, add scope without changing deadlines, work longer hours or even stop writing tests for our code, all of which incurs technical debt. All we seem to do is complain about having to work harder which falls on deaf ears as our business sponsors are also being asked to work harder by their bosses.

But what if we were able to quantify technical debt? Can we put a dollar amount on a decision to increase scope in an upcoming release? Can we quantify how much it will cost by not having a suite of unit tests and functional tests supporting our code? Our business sponsors most likely have gone through a cost justification for the project so costs rather than effort would mean more to them.

The best metric that I have seen to date has been the waterfall methodology's quantification of the costs to a project by introducing changes in requirements late in the release cycle of a project. The graph below illustrates how the cost of a change request grows exponentially throughout the Software Development Lifecycle (SDLC).



This chart illustrates how a change request during Pre-Production can cost as much as 100x more to the project than if it would have cost the project by introducing it during requirements gathering. This high cost of change requests comes from:

• Needing to update documentation
• Needing to update acceptance tests
• Complexity of the change within an established code base, therefore needing more time
  
• Time to fix defects introduced to the code base as a result of changes
• Needing to re-run acceptance tests after the change has been implemented
  

In a waterfall managed project, it is seen as a success to defer a change request to a subsequent release. But one thing that is hidden in the chart above is that the cost of the change request that has been deferred to Version 2 in a waterfall project can be as expensive as incurring the cost late in the initial release. The only difference in Version 2 is that you have more time to put in the change. But it is still costly. All the things that make change requests costly late in a project are still there during development of Version 2. Therefore, Version 2 is often delayed or reduced in scope because of incurred technical debt inherent within the waterfall approach.

The Agile community has come up with a solution for technical debt - don't pay it. Keep your documentation light and write tests first. Continuously refactor and build/test the application early and often. What we haven't done well is quantify or document our successes to show how effective these practices are in releasing subsequent versions of an application.

One of the development teams at ThoughtWorks that I had the pleasure of serving as Project Manager and Iteration Manager (along with some talented folks from the client's IT staff) has recently delivered Version 2 of a successful application for a Fortune 50 company. With Version 2, the team went through a significant refactoring of the object model, added a significant amount of new functionality and kept the code base approximately the same size as Version 1. There were virtually no defects found during testing of Version 2. In other words, technical debt was not incurred during Version 1 and therefore the overall quality of the code was allowed to improve during Version 2 development. The client received the functionality they expected when they expected it. We owe this to the team's diligent application of XP development practices of test first, continuous integration, simple design, well written story cards, constant collaboration with the customer and fearless refactoring.