Technical Debt

This concept is one I have fought (I mean discussed fervently) with upper management throughout all my technical career. I was never ever to fully quantify it, but instead used my own little adage that went something like this:

I can give you:

• Great Functionality
• A great delivery date
• Exceptional quality

Of course, management would always say, yep, that's it, that's what I want. My comeback, Pick Two!

I never could be very scientific about it, I would tend to lean on some common sense, or the old, Whack a Mole mentality. If you cut the date, either you are going to shortcut the function or the quality. Lets make sure we all understand that it's the date that counts. You have to make the date and have to deliver all the functionality required. How many of you have been involved in this discussion? And of course, what ends up being hit, is the quality. This was especially an interesting parable as the latter part of my career I dealt with High Availability products, you couldn't have poor quality. We managed very well, don't get me wrong, we delivered extremely high quality products. But, this game was part of every release cycle.

As part of my ongoing research, I came across an article written by Ryan Shriver on Technical debt. You can find this article at http://www.gantthead.com/article.cfm?ID=258854

Wow, here it is all laid out. I felt a bit embarrassed to find this term was first identified in the early 90's. Goes to show another one of my favorite quotes, It's what you learn after you know it all that counts.

There are many discussions and definitions here, but as always, pictures talk the loudest:


Technical Debt Chart from Jim Highsmith

Now, looking at this article, many links and recommendations can be found to deal with attributes of troubled development organizations, such as:

• Poor Customer Responsiveness
  
• Long Delivery Times
• Late Deliveries
• Too Many Defects
• Rising Costs
• Poor Morale

Technical Debt is not the answer to all these issues. Process, measurements, and other factors do come into play. But, as I have stated earlier, measurement is the key to everything. If you can't measure it, you can't improve it.

Ken Zaiken

If you fail to plan, you have planned to fail ...

There exist much discussion as to who really initially penned this profound quote. Some attribute this to an ancient proverb, if so, shows we really shouldn't underestimate the insight of those who came many generations before us. Remember, those who do not study history are deemed to repeat it.

I have been doing more and more with project management and my professional opinion as to the key components of a successful project:

1. Requirements
2. Planning
3. Communication

At a recent seminar I attended, the topic focused on key questions to ask for projects, and one item hit me that I had not fully verbalized before, the aspect of visual requirements. If a project has a requirement for a report, and the stakeholder even has a writeup for the report and the data that drives it, many times that may be taken as great input and move the project forward from there. However, a report can take many forms, and trying to resolve that once you have a team and working on the planning stage can lead to a lot of confusion and schedule delay. While it might take longer to actually get into gear, having a draft form of the report, graphs, word templates, whatever, will save a lot of time further down the project path.

A second item I have encountered is with clients who have not had previous experience with a formal project process. This is especially true with setting up the parameters of a project, an initial charter document. The biggest surprise is when the client is asked to sign that document, not so much to pour cement, but as a communication medium to fully understand the aspects of the project. Even in this digital age, putting a printed document in front of someone and asking to agree in writing sends a powerful message.

This does not mandate that what was perceived in the beginning of the project is not modifiable. But it does set a baseline that the base set of schedules, estimates, and costs are set from. People will always ask for more with less, that is human nature, but, we all do need a form a governance to have mutual respect in getting the job done. After all, that is what we all are working together to achieve, correct?

So, think twice before jumping headfirst into a project, assigning resources, and incurring costs. There is a great Dilbert out there that has the punch line, you start coding, I'll go figure out what they want. That is a plan to fail, instead, take the time to plan to succeed !!!