What factors make technical debt give way to the need for technical bankruptcy?

Question

I was having a discussion about technical debt with a coworker yesterday. I said something to the effect of "well, maybe what you need to do is declare 'technical bankruptcy'". In other words the amount of technical debt in the project has gotten so out of hand (we're talking 10+ years of a variety of developers and managers working on one application) that it seems like you just need to scrap it all and start over.

I got to wondering how you would sell something like a technical bankruptcy to management. Maybe a radical shift in technology, like the introduction of the .NET Framework? A desire for an enhanced UI, like Silverlight? When do you decide to shoot the horse and go back to the stable to get a new one?

Answer 1

Scrapping a project entirely is probably never a good idea. To quote Joel Spolsky:

Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

It's a bit smarmy of me to criticize them for waiting so long between releases. They didn't do it on purpose, now, did they?

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

Generally, a better idea is to take portions of the code base (discrete parts) and refactor them in place.

Answer 2

As always, I would sell it to management in terms of cost. Is it going to cost more developer hours to modify your existing code to meet a goal than if you just re-implemented from scratch? If so, you have a very good case to bring to management, whether you're talking about a new technology or re-implementing using the same technology.

For what it's worth, I've done this in the past, and one thing to beware of is that it can be a big morale hit for people who've invested a lot of their time into the current code base to have their contributions scrapped. I would try to build consensus among developers as well as management before making a decision like that.

Answer 3

Management only understand terms related to money. It's probably not going to be easy to sell them on features when the current features are working for them.

What they want to hear is that if you re-write now you are going to get a 50% ROI. Etc.

Answer 4

If your code is such an absolute mess, you should be trying to sell management on hiring better developers or training existing ones instead.

I know that even the best developers can produce bad smelling code. However, if it's so bad that you are strongly considering scrapping it, maybe you should invest in improving your team's skills. If you don't, you'll just end up in the same situation again.

Answer 5

10+ years of work from many developers is a lot to just throw away and a rewrite is not guranteed to produce anything better anyway, especialy if the culture of the company (which IMO has a far bigger effect on the quality of software than any single bad developer can) hasn't changed in those 10 years. You are better off asking for extra time when adding new functionality so you can refactor as you go along.

Answer 6

I worked for a company who was in a simillar situation. A decision was made to start over and for many many reasons, the project failed. They now have a good framework and are building new applications on top of it but have been unable to migrate the legacy ASP / VB6 code over. Trying to rewrite 10 years of history from scratch takes a long very long time.

And I bet there are business rules threaded in various places that people don't understand or aren't documented so not only will you spend a lot of time rewriting the whole application but you could loose functionality.

Migrate the application piecemeal, start breaking it down into chunks and convert the chunks over. You have to pay of the technical debt. If the app is a web site, with databases, how confident will you be in migrating thousands of people over night?

Answer 7

Let me start by saying that historically - from my experience - all projects put into place for cost savings based on reduced maintenance, cheaper hardware, easy modifications - have failed since they tend to overrun budget (to get past management these projects seem to be provide aggressively low budgets) and not be able to provide hard (truly reportable) and substantial benefits. SO - I would not approach a complete rewrite, but take it in stages of first de-coupling sections of the systems and then performing refactoring on the smaller components as needed - smaller chunks of budget being required for each and providing management with proof of concept/benefit.

Answer 8

Everyone says just refactor it and replace it piece-meal. But what if the app is so tightly coupled that the refactor part becomes prohibitively time-consuming and prone to failure?

That's when I think a rewrite is your only option.

Answer 9

Technical debt leads to technical bankruptcy when the cost of maintaining the debt is greater than the income.

But just as with financial debt, you don't scrap your assets, debt ridden though they may be, when you declare bankruptcy.

First you assess everything you have, salvage those things that are either too critical to lose, or are worth more than their cost of maintenance.

Then you write down your debt - count as a loss everything that can't be salvaged, and replace it.

Anyone who looks at a whole system of code and says, "Nothing can be salvaged" has not truly evaluated everything in the system, and is putting themselves at greater risk of loss.

Answer 10

When refactoring and fixing bits of a project isn't a sane option.

Some systems up for a rewrite where I work are over 20 years old. The people who can fix them are getting closer and closer to retirement, and there isn't a huge pool of developers for what the systems are written in. How many people have heard of, let alone used, Mapper nowadays? Replacing bits of the system with something more modern is messy and difficult; routines to shuffle data between Oracle and Mapper are difficult to write and tough to maintain.

The people who understand and work with those systems are still with the company, so it's a perfect time to rewrite. They can take roles in the project and assist with the design so the knowledge gained over the last decade or more isn't lost.

Editing for clarity: This isn't the only time it makes sense, but is definitely one where something needs to be done.

Answer 11

Rewrites should be considered an absolute last option because the cost is almost always way more than estimated, and even worse has a longer critical path to achieve anything. At least double, often triple, and that assumes a realistic estimate. I think there should be three prerequisits:

The technology has to need to change. It isn't just a matter of not liking how you used it. For example, your app is a windows client app in a RAD environment that won't let you encapsulate and expose business logic, and now you need to do a web based app. Not that you think the design is highly coupled in a Java app and could do better rewriting it. You will always be more successful refactoring it. If you think you don't have the skills to refactor, you also don't have the skills to pull off a successful rewrite.

Don't change any business logic until after the rewrite is out. You can design for the changes, improve the model to accommodate known design flaws, etc. But don't actually have any additional features as part of version one. Add them as enhancements afterwords.

If at all possible, get the project done quickly enough to avoid further development on the old product.

2 (Don't change business logic until after the rewrite) is often politically impossible to achieve, but without it the project will only every launch if management has a high tolerance for budget overruns and huge time delays.

Answer 12

A project at a company I worked for was in a great deal of technical debt a few years back. Even with half the team dedicated to reducing debt, they never even put a dent in it since the other half were either adding in new debt or updating code that a debt reducing team member was trying to improve.

The CTO declared Technical Debt Protection (after getting sign-off from the existing customers). During this phase they only worked on technical debt: no new features, no new customers. The team was given 6 months. If, after 6 months the debt was not reduced to an acceptable level, then the cancellation of the project was a serious consideration.

Fortunately, the 6 months payed off big time and the project was in great shape.

However, this would have been the point at which the project was scrapped had it gone the other way.

Answer 13

Even if you declare "technical bankruptcy" and completely start over from the ground up, that doesn't get rid of your problem.

Odds are that you have users/customers out there with the old system that will need to be supported until the new one is ready... the only way they're going to "go away" is if they choose one of your competitors.

Even worse, if you're moving into a new technology/architecture/whatever that your team isn't 100% behind, you'll likely lose some members... you know, the guys that are vital for fixing things for your current customers.

Before going the bankruptcy route, you need to seriously consider the ramifications... it's not something you can un-decide easily.

Answer 14

You have to look at the future costs. The standard business method is "net present value" (NPV). Spreadsheets have this function built in. Basically it takes a future cash flow and an interest rate and works out how much that future money is worth right now. So you have to make some assumptions about future costs to maintain the existing system versus the cost to rewrite it (including "opportunity costs" due to not getting anything else done in the meantime). Then take the smaller number. Management will be happy because they understand NPV, and its actually not a bad way to make the decision.

One way to make the rewrite costs substantially smaller is to use a better language. If your old horror is written in C++ then you can cut costs in half by writing in Python, and probably a quarter or more if you write in Haskell, Erlang or Scala. This will also impact the future maintenance costs for your rewritten app. You may find you can do a rewrite for less than one or two years maintenance of the current app.

If the existing application is used in-house then you need to spend a lot of time understanding how the organisation interfaces to the app. Applications and the organisations that use them tend to co-evolve in complicated ways, and this is probably your biggest source of cost and risk. The organisation will want something that works exactly the same way as the old program, even down to the awful UI. They have a point, but you also need to look for places where a new program can improve efficiency, and plug those opportunities into your NPV cost model.

Answer 15

There are no good options or easy answers. If you are so burdened with technical debt that you spend most of your time refactoring, trying to understand the code, fixing bugs, etc that you can't innovate and add new value to the product, the business built around your product is going to stagnate and eventually collapse under your own weight. In my opinion you have 5 options:

• Rewrite the software from scratch
• Refactor and incrementally improve over time
• Pay down your debt in a large chunk
• Live with it
• Find a new job

If you can sell re-writing to the company, that is the only viable approach for continuing with the product, but you have to sell it to the business and they will be spending a lot of money to get no new features for up to a couple of years.

Refactoring and paying down your debt over time won't work. Consider it as a financial debt: it takes 23 years and $7000 to pay down a $5000 credit card debt making the minimum payments each month. Even if you do go the refactoring approach, you can't add any more technical debt which means fundamentally changing your development practices.

Paying down your debit a large chunk probably won't work. Its a tough sell to the organization and if your problems are architectural, you may not be able to address them in a limited time period. At best, you will be delaying the problem.

In the long run, living with the technical debt isn't viable, or we wouldn't be asking the question about what to do with too much technical debt.

Finding another job might be your best option. If you enjoy designing and developing new software and creating value, them this might be right for you. Just make sure you learn from being burdened with too much technical debt and avoid the problem in the first place in your next job.