Sunday, 27 June 2010 00:00

The Snake Pit, Taking the Poison Out of Technical Debt

Rate this item
(0 votes)

Projects build in technical debt and maintenance groups remove it—if your organization has a maintenance group. Technical debt accrues in any product, whether or not it has a technical component. It is the result of taking shortcuts when building the product. Sometimes it is the result of not having enough time, on other occasions it is due to not having the right tools. Anything from the implementation of the software component to light fixture can have technical debt. Promises are made to correct it later, but later never comes.

Case Study: The "Snake Pit"

Recently there has been a resurgence in the popularity of the article Using Agile in a Project Recovery. As with any new implementation, there were a few problems—technical debt was one. One was experienced in the third iteration; a bug was introduced in the release. Because of the short development and testing cycle regression testing was constrained to a logical set of tests based on what was changed. However, this bug was in an area that was not worked on, so regression testing missed it. I asked the architect and the QA lead what went wrong. The architect regrettably shook his head and relied, "The Snake Pit." I had heard the developers refer to this before. It was a section of code that had been modified too hastily by too many people, too many times. The code was a mess, poorly written, and not well understood. I asked the architect to come back and give me a recommendation.

The next day Bob came back and told me that the four-week release cycle could not continue. The code was written so poorly that we would continue to trip over unexpected functionality. We got the developers together and talked about the options. The developers were very frustrated. In my haste to implement the process, I had missed telling them the importance of refactoring the code base. I told them that their estimates had to include a sensible amount of time to refactor the code.

Two guidelines were defined to help:

  1. Changes had to be sound. They could not be hurried; they needed to be able to be completed in a short amount of time.
  2. Additionally, each iteration had a few days set aside for unanticipated refactoring. When they touched code that was poor quality, they were supposed to change it.

The developers were ecstatic. They had never been given this leniency to use their discretion at how to do their work. Needless to say, the organization was not one to trust the judgment of its employees. This, and the implied trust that went with it, made pride soar.

Technical Debt's Effect

Trying to fix technical debt in a product can be a monumental, especially if it has accrued over time. Estimates for project work are often created with the assumption that the code base is sound. However, when the team starts working, they find that the product was not built to best practices or shortcuts were taken and now, before the enhancements can be added, the mess needs to be straightened up. This effort can be significant. The customer, of course, does not want to hear any of this, since they do not feel they caused it. It is up to the project to fix the code and make it maintainable.

It is worse than this, though. Technical debt is not just from poor practices. Products simply go out of date. Techniques and tools change, new products emerge, and better methods make the old structure passé and fragile. When adding new functionality, it usually does not makes sense, and sometimes it is impossible, to continue to use the old style. There are times that a remodel, or refactor, is a necessity. No one is to blame, it just needs to be added to the scope.

The Maintenance Group

Attending to technical debt is a never-ending process. A maintenance group is the best group of people to do this work. They can do this between projects providing a solid code base for the next project. However, budget cuts have relegated this to a luxury. This is a short path to a non-maintainable, costly, bug laden product.

Handling Technical Debt in a Project

As highlighted in the case study (see inset), technical debt is a serious issue. The best defense is a good plan. Discovering the problem early is critical since it gives the team time to understand its breadth and potentially start working on fixing it prior to working on the project's product.

The worse case is when the project team tries to remove technical debt and the project is not equipped to do it. This can be a result of two conditions—the project does not have the funds or management has made a decision to make a quick fix. Technologists hate these situations since they feel they are developing substandard product and will need to fix it at a later date. The case study in the article Finding Religion, Trusting Management describes just such a situation. Project managers need to pay special attention to stop this work.

Read 3778 times

Related items

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)

    Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

    No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap