Skip to main content

January 2012

Code Debt


Several years ago, as a young programmer recently out of graduate school, I joined a small company and inherited a large amount of code that had been created by a previous employee. The code implemented a complex user interface and I had received several customer product change requests.

A sizable amount of the code had been automatically generated sometime prior to my involvement through the use of a user interface design tool. The tool allowed a non-programmer to graphically define the parameters of the user interface while magically generating working code on their behalf.

If any of you who have ever seen automatically generated code, you know that it's hardly fit for human consumption. The code typically has poor structure, much redundancy, and no domain knowledge.

After the automatically generated code was created, other programmers had made additional code changes, which meant the design tool could no longer be used, resulting in a horrific mixture of poorly generated code liberally sprinkled with many hacked-in changes.Code Debt

Now back to my role in this story; I studied the code carefully and found that I could scarcely make sense of it. I could sort of see how the other programmers had tried to fix various issues, but I had no luck determining how the generated code was fully operating. It became clear that any new functionality requests could not be developed using the existing code.

Next I made the same mistake so many young, overly confident developers make. I told my boss I'd work over the weekend and fix it. He looked at me over the top of his glasses and said, "You do that."

To make a long and very painful story short, I threw away the existing code and rewrote everything from scratch with zero documentation on how the code was originally intended to function. The project impacted the company financially, operationally, and created a negative customer perception. Costs were tallied based on the missed product release deadline, numerous customer complaints, development time, missed opportunities, and some lost product functionality, resulting in frenzied hot-patching.

Today, as a much older and wiser (I hope) software development executive, I look back on this painful event knowing that my decision to rewrite the code caused a great deal of hardship, lost revenue, and costs. I also know that the code that I inherited had been so poorly maintained prior to my arrival that no other choice could have been made.

While I was clearly culpable, the culprit here is a concept known as code debt.

I invite you to read the Wikipedia article titled, Technical Debt. The article explains that code debt is commonly caused by: business pressures, lack of process or understanding, lack of building loosely coupled components, and lack of documentation.

The code I had inherited was literally a big pile of code debt. For years prior to my involvement, various programmers had been pushed hard by business stakeholders to make quick changes for near term and inexpensive customer requirements. The programmers didn't really understand the code in its entirety as no documentation existed in terms of original requirements or change requests. Programmers simply hacked in changes without complete understanding of its effects. Additionally, no time was allocated to refactor the code into something better and more maintainable.

Well designed code that is documented, understood, and surrounded by good unit tests is relatively easy and safe to change. The weeks of development work I dedicated to whip the user interface into shape was literally the interest paid on the debt. I'd also bet that the other developers prior to my code overhaul had also paid some amount of interest simply by attempting to decipher the code.

The objective cost of the interest is hard to measure, but the subjective cost of code debt is often extremely high. Code debt is responsible for many cases of late releases, buggy code, under-performing code, non scalable code, high development costs, high test costs, unhappy customers, and abject project failure.

Just like real debt, code debt is easy to ignore. Stakeholders want to hear, "I can do that in two weeks" not "that will take four months." Non-developers often take the "How hard can it be?" approach to product development. Developers are typically optimistic and want to please while customers want the new functionality tomorrow. All together, it's a recipe for building up code debt. All involved have the tendency to say, "Let's just do this quickly now and fix it all later." Doing so adds to the debt and the debt grows in some non linear fashion.

The best way I've found to avoid code debt is to use an Agile process and a focus on the following principals taken from Extreme Programming:

  • Coding standards
  • Simple design
  • Refactoring
  • Testing
  • Pair programming
  • Continuous integration

Code debt adds to the complexity of resource planning. As IT professionals, we are continuously challenged with making better use of limited resources and focusing those resources on work that brings value to the organization and aligns with corporate goals.

I'd love to hear from you. What are your experiences with code debt and what have you done to prevent it from taking place in your organization?

Three Signs Your Organization is Ready to Implement Product Portfolio Management


Your product pipeline might be perfectly streamlined and efficient. But if you're like many organizations, your portfolio may have some issues that are costing your organization in terms of revenue, product failures, and eventually reputation. Maybe you've wanted to implement a Product Portfolio Management Solution but haven't defined or designed your processes yet. Did you know that it's actually recommended that you go ahead and get started with a PPM solution so you can grow your processes as you go along? Here are some sure-fire ways to gauge whether it's time you invest in a software solution to improve your chances for success.

  1. Failed Market Launches
    Has your organization launched unsuccessful products that have blemished your brand or product line? Have you missed critical time-to-market deadlines that have cost real money? Product Portfolio Management allows you to analyze your portfolio before you make the decision on what will be on your roadmap. It enables you to evaluate every piece of your portfolio so you have a complete picture -- the impact on your brand, competition, resources, sustainability, and bottom line. What has a failed product launch cost you? Chances are, a lot more than what it would cost to implement a solution.

  2. Limited Resources
    You've repeatedly heard and our recent Benchmark Surveys have confirmed that the #1 pain point around Product Portfolio Management is too much work for available resources. You may have people presenting great ideas, but you only have a limited capacity when it comes to people. If you say 'yes' to every good idea, you spread your resources too thin and few of those good ideas actually make it to the market on time. Product Portfolio Management gives you tools to run 'what-if' scenarios before you execute. It allows you to perform comprehensive portfolio analysis to understand your current capacity, usually based on role or skill, and then evaluate all of the things in your pipeline to go on the roadmap to ensure they can actually get done on-time with the available resources. When you use your resource capacity as a filtering mechanism, you have a much higher chance of success.

  3. Market and Product Conditions
    Look at the size of your product catalog and the number of markets you serve. If you have a large number of products, multiple projects that deliver a product, a large number of metrics to analyze the performance of each product, multiple markets or global markets, or if your roadmap is frequently changing, you're ready to centralize and automate your product portfolio to maximize visibility and reduce risk. Are you still updating your roadmap manually through PowerPoint? That's a not just a sign, but a neon flashing sign telling you it's time to convert to a formal solution.

Take a look at your current product portfolio and see if any of the 3 signs above are present. If so, you just might be ready to call in reinforcements!