Sorry, this is going to be long, but it's based on personal experience as both architect and developer on multiple rewrite projects.

The following conditions should cause you to consider some sort of rewrite. I'll talk about how to decide which one to do after that.

• Developer ramp-up time is very high. If it takes any longer than below (by experience level) to ramp up a new developer, then the system needs to be redesigned. By ramp-up time, I mean the amount of time before the new developer is ready to do their first commit (on a small feature)
  • Fresh out of college - 1.5 months
  • Still green, but have worked on other projects before - 1 month
  • Mid level - 2 weeks
  • Experienced - 1 week
  • Senior level - 1 day
• Deployment cannot be automated, because of the complexity of the existing architecture
• Even simple bug fixes take too long because of the complexity of existing code
• New features take too long, and cost too much because of the interdependence of the codebase (new features cannot be isolated, and therefore affect existing features)
• The formal testing cycle takes too long because of the interdependence of the existing codebase.
• Too many use cases are executed on too few screens. This causes training issues for the users and developers.
• The technology that the current system is in demands it
  • Quality developers with experience in the technology are too hard to find
  • It is deprecated (It can't be upgraded to support newer platforms/features)
  • There is simply a much more expressive higher-level technology available
  • The cost of maintaining the infrastructure of the older technology is too high

These things are pretty self-evident. When to decide on a complete rewrite versus an incremental rebuild is more subjective, and therefore more politically charged. What I can say with conviction is that to categorically state that it is never a good idea is wrong.

If a system can be incrementally redesigned, and you have the full support of project sponsorship for such a thing, then you should do it. Here's the problem, though. Many systems cannot be incrementally redesigned. Here are some of the reasons I have encountered that prevent this (both technical and political).

• Technical
  • The coupling of components is so high that changes to a single component cannot be isolated from other components. A redesign of a single component results in a cascade of changes not only to adjacent components, but indirectly to all components.
  • The technology stack is so complicated that future state design necessitates multiple infrastructure changes. This would be necessary in a complete rewrite as well, but if it's required in an incremental redesign, then you lose that advantage.
  • Redesigning a component results in a complete rewrite of that component anyway, because the existing design is so fubar that there's nothing worth saving. Again, you lose the advantage if this is the case.
• Political
  • The sponsors cannot be made to understand that an incremental redesign requires a long-term commitment to the project. Inevitably, most organizations lose the appetite for the continuing budget drain that an incremental redesign creates. This loss of appetite is inevitable for a rewrite as well, but the sponsors will be more inclined to continue, because they don't want to be split between a partially complete new system and a partially obsolete old system.
  • The users of the system are too attached with their "current screens." If this is the case, you won't have the license to improve a vital part of the system (the front-end). A redesign lets you circumvent this problem, since they're starting with something new. They'll still insist on getting "the same screens," but you have a little more ammunition to push back.

Keep in mind that the total cost of redesiging incrementally is always higher than doing a complete rewrite, but the impact to the organization is usually smaller. In my opinion, if you can justify a rewrite, and you have superstar developers, then do it.

Only do it if you can be certain that there is the political will to see it through to completion. This means both executive and end user buy-in. Without it, you will fail. I'm assuming that this is why Joel says it's a bad idea. Executive and end-user buy-in looks like a two-headed unicorn to many architects. You have to sell it aggressively, and campaign for its continuation continuously until it's complete. That's difficult, and you're talking about staking your reputation on something that some will not want to see succeed.

Some strategies for success:

• If you do, however, do not try to convert existing code. Design the system from scratch. Otherwise you're wasting your time. I have never seen or heard of a "conversion" project that didn't end up miserably.
• Replace the old system team at a time. Identify the teams that have the MOST pain with the existing system, and migrate them first. Let them spread the good news by word of mouth. This way your new system will be sold from within.
• Design your framework as you need it. Don't start with some I-spent-6-months-building-this framework that has never seen real code.
• Keep your technology stack as small as possible. Don't over-design. You can add technologies as needed, but taking them out is difficult. Additionally, the more layers you have, the more work it is for developers to do things. Don't make it difficult from the get-go.
• Involve the users directly in the design process, but don't let them dictate how to do it. Earn their trust by showing them that you can give them what they want better if you follow good design principles.

I have participated in two big rewrites. First was a small project. The second was the main product of a software company.

There are several pitfalls:

• rewrites always take longer than expected.
• rewrites have no direct effects/benefits for the customer.
• capacity devoted to rewriting isn't used to support the customer.
• you will lose functionality with a rewrite unless you have 100% documentation.

Rewrites are seldom the real answer. You can refactor much of the code without losing anything and without a lot of the risk.

Rewrites can be the answer if:

• you are switching to another language or platform.
• you are switching frameworks/external components.
• the existing codebase is not maintainable anymore.

But I strongly advise the slow approach using refactoring. It's less risky and you keep your customers happy.

It's time for a rewrite when:

The cost of rewriting the application + maintaining the rewritten application is less than the cost of maintaining the current system over time.

Some factors that make maintaining the current one more expensive:

• The language is so old you have to pay people that know it a lot of money to program in it (COBOL).
• (from experience, unfortunately) The system is on a hardware architecture that is so old that they have to scour Ebay and COLLECT parts to add to the machine it is running on because they aren't made anymore. This is called "hardware life support" and is expensive because as parts become more scarce, they (may) go up in price or they (absolutely) will eventually run out.
• It has become so complex that the //Here be dragons. comment is all over your code.
• You can't write any other projects and add new value to the company because you're always patching this ugly beast.

If you require a fundamental change in the architecture of the project, it is possibly time to start afresh.

Even with that, there will potentially be large swaths of code that are still worth re-using in your new project.

Heed fair warning though. A current project will have had its business rules tested and refined with countless man hours of actual usage, something that will not be true of a project started from scratch.

I doubt a time frame or gut feeling is an appropriate measure of such a drastic measure. You must have clear, defensible and well understood reasons to partake in this course of action.

Although I do agree with Kramii's answer and Joel's opinion, there are times when it is appropriate to do a rewrite. In long-lived applications (I'm talking like 10-20 years or more), maintenance becomes more and more expensive over time. This is due to the code becoming more and more spaghetti-ish as the original architecture is sacrificed for quick maintenance patches. Also, developers for older technologies become more rare and more expensive. Finally, hardware begins to age and it gets harder and harder to find new hardware, operating systems, frameworks, etc. to run the old application on top of. Also, businesses evolve, and most likely an older system will not be meeting the business needs of the organization as well as a brand new system could.

So you have to weigh all of the ongoing maintenance cost, as well as the potential benefits of a new system to the business, against the cost of rewriting the thing from scratch. Be very pessimistic in your estimates about the cost of a rewrite. It almost always costs more and takes longer than you would think.

I worked for a small software company that had a couple of DOS applications that were upgraded to handle Y2K, rewritten as a Windows 16-bit app and then totally rewritten as a 32 bit app with one additional 'small' feature (ultimately only utilized by one customer) that impacted the entire structure.

Moving the 16 bit code to 32 could have been done in a month by one person, but NOOOOOOOOO, we had to rewrite it to make is Soooooooooo much better. This thing could be adapted for other industries, would have full specs and psuedo-code before they even got started. The specs were created, but it took so long there wasn't even time to write the real code. It was released late, with more bugs than the 16 bit 'started' with (it was on v.3.0 and finally to the point where we almost made it a week without someone reporting a new bug).

You'd think rewriting the same application 3-4 times would bring about some improvements, but I just don't think a GUI front-end can be justified that much.

This was my first IT job as head of technical support. I should write a book on how not to develope software for distribution. Obviously we made many mistakes, but the fact that we continued to rewrite applications compounded the incompetancy.

I think I'm in the only situation in my career where the big rewrite is the answer:

Company merger, huge overlap in systems functionality. Many, many systems have been merged and retired, and others still in the process.

I've inherited a system from the other company that still lives on. It has a huge code base, which used to support multiple departments very similar to our own, but with a completely different design and frameworks. There is only one business sector left using it, which makes enough money that keeps this thing alive in a zombie state. All the old expertise is gone, there is no documentation. The support burden is high, with failures every week. It has not been merged into our companies systems, because our company never supported this particular sector of the business, so we don't have the functionality or expertise.

It looks like this is the one case where the rewrite is needed. It looks like I'm going to have to figure out this behemoth, pull out the bits of functionality dedicated to this business, and rewrite the pieces that need to be added to our existing systems. Once that is done, our existing systems can support this new sector, and this beast can be put out of it's misery. Otherwise I'm going to lose my sanity.

I have similar thoughts to Joel Spolsky, but in a domain outside of internet browsers.

At a former company we attempted that epic rewrite. It did pretty much everything wrong you could think of, from over-hyping the rewrite to the customers to the attitude behind it. For 3 years we labored hard with no product, only an embarrassing prototype, until we abandoned it and came back to the old one. The damage to the company's reputation was never fully recovered, as well as its morale.

Yet one of the things that bothered me personally, even when we decided to do it, was that the team echoed a similar attitude you did. When asked about the product, all they could talk about were the negatives. And they were justified, the codebase was a stinky mess. We actually had C functions that were 20,000 lines of code with hundreds of variables declared at the top, and that wasn't some one exceptional case in the system, that was the norm (our product had a 3-decade legacy). But they had little good to say about the actual product, its workflows, its designs, which tens of thousands of users worldwide loved and used.

A Remake Requires Love

Imagine taking a classic, beloved film and having a film director who has nothing good to say about it be in charge for remaking it. Is that going to have a reasonable chance of success? Almost certainly not, and yet teams compelled to do rewrites often approach it with this kind of attitude. To remake anything requires love for the original, not hate.

A rewrite doesn't just boil down to time, and the time will always be longer than expected. There is design continuity here. If you have this legacy product and there was a compelling enough reason for a company to continue paying the staff to work on it, it probably has a reasonable customer base of people who love it, depend on it for their livelihood, etc. They don't see the stinky codebase.

Now, take a team who absolutely hates that codebase. In a worst-case scenario, this would be an even different team from the original team that designed the legacy product. This exposes us to a very high risk of creating something which customers like even less than the original. This is especially true if the team is blinded so much by the product's technical flaws that it can no longer see what it did right.

Refactoring

So I really recommend refactoring, at least trying very earnestly here as a first step. Don't even consider a rewrite until a genuine attempt is made unless there's some reason that forces a rewrite (ex: a change to a new programming language and hardware/operating system that doesn't allow the former one to be used).

But moreover, refactoring or rewrite, there needs to be an appreciation for the good user-end aspects of the original product. There needs to be an appreciation and faith for the decisions of the original product that turned out to be a hit with its user base. Until that is appreciated, no substantial change or rewrite of the original product can have a good hope of achieving the success of the original.

It takes a much longer time to go from a fresh product with potential to a mature, tried and tested product. The latter can take 10 years, the former might be doable in a year.

Another thing to keep in mind is that appeasing existing customers for a rewrite is typically a significantly higher priority than gaining new ones. If the desire is to reach a whole new customer base, then it would be a new product rather than a rewrite. It shouldn't even live in the shadow of the original. But if it's a rewrite we're talking about, existing customers are the most important.

Anyway, those are my two cents, and they're very much aligned with Joel from having had a not-too-dissimilar experience.

I had a case very similar to yours only the code wasn't even using Struts. What I did instead was target areas that were particularly crappy AND causing a lot of problems. This targeted approach got us incrementally better.

Over a 2 year period we worked on refactoring bits and pieces alongside enhancement work. We always worked a 'Hardening' task into a project plan. By focusing on the specific areas that didn't work well we got the most bang for the buck. The stuff that worked we left alone. Also critical is that this work was done in the course of normal development and was released. The problem with a big rewrite it you go off for a year or more and then by the time you come back every things changed anyway and some of the nasty bugs got smoothed over and you lost your ROI.

We never did re-write the whole thing. We did stop using that platform for new work though, and pitched a new fresh platform for a big new project. That got approved and we delivered a great product in a reasonable amount of time.

So here I am sitting at my desk, I started re-writing the code for this absolute mess of one big aspx file, the database behind it, and replacing the MS Access interface to the MsSQL.

This asp program is littered with things like

• include(close.aspx) which inside has one line of code that closes the last open database connection.
• Legacy code just commented out randomly
• No consideration for security
• Spaghetti code, thousands of lines of it. All in one file.
• Functions and variables with no clear meaning behind their names

If we ever need to make a slight change, it's like playing five simultaneous games of kal-toh on nightmare mode.

I was hired to replicate functionality and make a product that could be customizable and salable to others in the industry. The problem is this thing has been written over the past 10 years to fill every single business need (well, I'd say about five or six sigma of them anyway).

If we didn't want to sell the product, they probably wouldn't have needed a re-write as it does most of what they want-- perhaps not elegantly, but it wasn't prudent to spend the money on making nice code 'do the same thing.'

Never, always refactor - the truth is if the code was written by you - you won't be able to do any better.

Unless you want to change technology, the code is lacking any structure (i saw it very long time ago in some PHP website, the author just copy/pasted spahgetti instead of include / class / function ) or you taken over something from another person that's very badly written.

Everything should be designed as a blackbox. Modular, Simple API, what is inside... that's less important :) If you have spaghetti you maybe able to close it inside a blackbox, so it won't contaminate good code.

The existing solution doesn't scale.

I'm looking at you, MS Access.

It's the answer when the rewrite allows the organization to pursue a strategy that affords a competitive edge or allows it to better serve its customers in some manner that the current architecture cannot accommodate.

Instead, rewrites often happen to alleviate management worries:

• everything should be in .NET,
• our developers say our code sucks,
• we're falling behind technically,
• we won't be able to find resources to support our system or, very often,
• it's been ten years so it's time.

Most of these worries won't materialize and, if they did, they could be handled. That last one, however, is the worst. It's essentially: we don't have a reason.

Yes, like car, a system will begin to show signs of wear. This can be alleviated by routine servicing. You know what they say about how a little preventative maintenance goes a long way. As an investment, routine servicing (i.e. refactoring and standardizing) will almost always carry less cost than a rewrite.

However, we have to anticipate that a rewrite will eventually be necessary. Set dates and tentatively plan for it, but as the date draws nearer delay in favor of realizing other strategic goals until you have a compelling reason like...

In recent years we've lost the opportunity to win big accounts because we couldn't accommodate their needs in a timely or costly fashion. Our system will be rewritten using an extensible architecture that allows customizations to be plugged in (and not hardcoded as we currently do). This will dramatically decrease the time and cost of accommodating customers with special needs. We'll win more accounts and better meet the needs of our current customers.

I think the main reason that justifies rewrites are for platform changes. For example, if you have a Windows desktop GUI application and the company owner decides they want the next version to be a web based application. Although not always, in my experience most of the time this will require a rewrite, unless the original developers wrote very modular and reusable code (hardly happens).

There's the classic joke about "if I was going to X I wouldn't start from here".

I took a job once, where the employer's prime motivation was to bring talent aboard to launch a long-overdue rewrite of a business-critical app. The question I failed to ask was, why have you ended up in this situation in the first place? It should have been a red flag, whether the cause was

• too much pressure to add functionality to maintain and incrementally refactor the beast,

• too little ability in the department,

• too little buy-in from clients or management for incremental work,

or whatever, and this cause festering away until the problem reached an intolerable level.

So I'm going to agree with Joel in that a massive rewrite is probably a very bad idea - unless you have firm evidence that all the underlying reasons behind why a major rewrite seems so necessary have been dealt with, you're in all likelihood going to repeat the problem in due course.

Well I can imagine hypothetical scenarios where I might just throw out the existing code base (hypothetical situations where the bucky balls have zero weight and volume, where no one cares if we lose weeks or months of productivity as we scramble to add overlooked features and bug fixes into the system, and where the system is so trivial and hated by an organization that I can replace the entire thing and army of servers with notepad++ and a netbook in ten minutes and boost everyone’s productivity and moral across the board.)

For almost any real world scenario though I would just recommend refactoring in place. ^_^. There tend to be too many hidden, unanticipated costs to rewrites when undocumented legal and business requirements start to pop-up and the last minute hacking things together last minute starts to ensue.

==Refactoring in Place for greater good, and stuff==

Refactoring legacy code with the regular old incremental approach,

1. If you have the chance convert to UML and document what little knarly architecture there is.
2. If you are on version control look into generating some code churn reports and figuring out which files and file sections have been changed the most frequently. Make a note of these as they will likely be the areas you will want to deal with first.
3. Before you change any code always try to add some test coverage (even ugly full stack functional tests will do). If dealing with large messy procedurial code extract logic you intend on changing into some reasonably named method or function and if possible add some test cases that verify your new method. make whatever god awful hack you have to and if possible paramatize the change if it is something commonly tweaked like margin width or title so it will be a little more straight forward to update the next time.
4. Use the adapter pattern and work away at hiding the knarly bits of legacy code under a rug of logically named classes and methods so that for most common tasks you and the other developers perform you wont need to worry about the scary bits that are going on behind your back behind those nice little clean methods and classes you've hidden that legacy code behind -- like those nice families that keep deformed murderous zombie former family members in barns so that they don't spoil the day to day going-on’s of the farm . . . normally.
5. As you continue to whittle away and clean up the sections of the code continue to boost your test coverage. Now you can dig down even deeper and "rewrite" even more code when needed/desired with ever increasing confidence.
6. Repeat, or apply additional refactoring approaches to continue to improve your codebase.

Branching By Abstraction

1. Define the trouble spot in the code you want to remove (the persistence layer, the pdf generator, the invoice tally mechanism, the widget generator, etc.).
2. run (write if necessary) some functional test cases (automated or manual but you know automated) against the code base that targets this functionality along with general behavior.
3. Extract logic related to that component from the existing sourcebase into a class with some reasonable interface.
4. Verify all code is now using the new interface to perform activity X which was previously dispersed randomly throughout the code(Grep the code base, add a trace to the new class and verify pages that should be calling it are, etc.), and that you can control which implementation will be used by modifying a single file.(object registry, factory class, whatever IActivityXClass = Settings.AcitivtyXImplementer();)
5. rerun functional test cases that verify everything is still functioning with all of Activity X throwin into your new class.
6. Write unit tests where possible around the new activity X wrapper class.
7. implement a new class with less insane spaghetti logic than the legacy implementation that adheres to the same interface as the legacy class.
8. verify that the new class passes the unit tests you wrote for the legacy class.
9. update your code by changing the registry/factorymethod/whatever to use the new class instead of the old class.
10. verify that your functional tests still pass.

Open Closed Principle and a Common Business Logic/Persistence Layer

To some extent you might be able to get away with separating out your presentation, business and persistence layer and writing a new app that is fully backwards compatible with the legacy solution, or at a minimum can still handle data inputted by legacy solution. I would probably not recommend this approach but sometimes it is a reasonable compromise of time/schedule/resources/required new functionality.

• At a minimum separate the presentation layer away from the business and persistence layers.
• implement a new ui and better presentation layer that uses the same common business and persistence layer.
• Verify that data created with new ui does not break old ui. (you're going to be in hot water if users of the new tool interrupt users of the old tool). If you are striving for full backwards compatibility you should be saving everything to the same persistence layers. If you just want forward compatibility into the new tool then use a new database and new tables or extension tables to track data not in legacy system.
• For new functionality and persistence layer needs add new tables and methods don't change existing legacy logic, or add columns, constraints to existing tables. e.g. if you need to start tracking employers emergency contact and some other fields don't modify the existing employee table (we have no idea what assumptions the legacy data makes about that table) add an extension table employee_ext id, employee_id, emergency_contact_id, etc_id.
• Slowly migrate users onto new system. if possible put legacy system into read only mode, or just add some warning telling users it will no longer be available after date X.
• implement any hi priority missed functionality or business requirements in the new ui
• roll over users base.
• continue on to clean-up the business logic and persistence layer users other refactoring methodologies.

To decide the point at which you should start over, you need to work out where the value of continuing on your current project falls short of the value in starting over.

The reason this is so difficult is that you make an accurate estimation of the team's development velocity on the new project until you actually start it. That said, if, using a VERY conservative estimate of your development velocity on the new project, the project is estimated to give a worthwhile return on investment, then you have a business case for starting afresh.

With my metric, you have to satisfy two conditions to justify a rewrite:

1. After the rewrite new features will be easier/quicker/less buggy to write
2. The rewrite will take less or equal time than adding the current new feature.

Even then you want to limit the scope of your rewrite. For an example, we had some legacy software at a company that was written in C++ with the mindset of a C programmer who didn't know about modularity. The end result was speghetti code in the form of a finite state machine that spanned multiple classes and DLLs. We had a new requirement that was very different from the assumptions built into the code, and was going to be part of the company's patented value-add to its customers.

After spending time with the code implementing other features, I had a really good idea of how long it would take to figure out which of the several switch statements I would need to change, etc. My proposal was to rewrite the section of code that was the huge finite state machine--it should take me less time than extending the existing code. I was able to consolidate into one DLL what used to be three, and provide a much more object oriented structure that would make it a lot easier to do the critical new functionality along with making it easier to add new functionality.

There were three other applications using the libraries that needed the rewrite, so I didn't want to have to completely rewrite those programs. The scope was limited to the library and what was necessary to bind the library to the existing software. My estimates weren't off by far, and the work paid for itself. Shortly after the redesign, I was tasked to add a new feature. What would have taken me a week with the old structure only took me a day with the new structure.

When moving to a completely new technology is needed to provide desired functionality.

"Completely new": if you're planning to rewrite but use the same platform, then refactoring and judicious restructuring is almost certainly the better solution. "Platform," as used here, is somewhat vague -- consider it to include language, and perhaps OS (extending from Linux to Windows or vice-versa comes to mind), but probably not framework (eg, replacing Struts with Spring).

"Needed to provide desired functionality": right around 2000, I initiated a project to rewrite a major server component in Java from C++ to enable out-of-the-box threading, an object cache, and client-controlled transactions. At the time, there were multiple threading libraries for C++ that we would have had to support, and thread-enabling much of our database code would have necessitated a near-total rewrite. As for client-controlled transactions ... not gonna happen with the old architecture.

Even then, I'm not sure that I would have done the rewrite, except that I had detailed knowledge of the current system's behavior, and it was relatively clean code that hadn't developed very many warts in its 11 years of life.

The OP doesn't indicate the scope of the project, but the main clue I took was "written in old [language/dialect] using old [libs]" which to me are the primary drivers of a re-write. In fact, most projects I've been on of any significant market longevity eventually realize that accomodating updates to compilers/interpreters/operating-systems is an important task in maintaining the code base.

In short, I would plan the re-write in phases, prioritizing first the update in libs. It might be that along the way, you can sneak in other optimizations, but the fact that you plan to defer some changes to a later phase can be a great way to stay on schedule and avoid getting "stuck."

I don't think I have ever seen people rewriting a legacy app.

What happens is that people are writing totally new apps with a different architecture, technologies,etc which have some features in common with the previous generation. And it is called app 2.0, but in fact it has very few things in common with the original.

But this is not really a "rewrite" of the original in the sense that you are trying to achieve feature parity.