【转载】避免软件重建失败的三种方案

Rebuilding your software to update the architecture is the riskiest development project you will ever dive into. Big, successful companies have been crushed by this task. The right tactics are essential. Recently, a more moderately sized company called me in to advise them on a much-needed rebuild, and we broke the tactical options down into three categories - "standard", "incremental", and "buy", each with its own advantages and disadvantages.

A personal story illustrates the risks involved. In 2000, I launched a rebuild of my PowerSteering product. There were all sorts of reasons to rebuild the product, the least important but the most motivating being that we wanted to make the product extensible in some exciting new ways. Over the long term, this turned out to be the right thing to do. We added a lot of new capabilities that customers appreciated. However, this was a crushing mistake for me personally. We were coming to market with this product in 2001, just as the big recession hit, and we were carrying the extra expenses of the product rebuild. We got some VC's involved, and they set to work with a well-oiled plan to fire me, strip me of the assets that I had invested in the company, and dilute me out of a meaningful shareholding. It was hard on my pregnant wife.

In this case, we had a rare controlled experiment. Someone else took the same code and went into an alternate universe without a rewrite. An entrepreneur had approached me to purchase full ownership of some project management code, so that he could turn it into a product for his startup. I sold him the OLD code for a nominal sum, with a stipulation that he should send me $200K if he ever sold it. He changed the front end to be more industry specific, but he never made any upgrades to the underlying code. A few years later, my (former) company got a check in the mail. It turns out he sold the company and the product for $6M.

Dharmesh Shah elaborates upon this lesson in
Why you should almost never rewrite your software
.

Why take the time and expense to rebuild software? Because after a while, it becomes harder and harder to do the things that you want to do. There is an ever-increasing amount of code that is structured incorrectly for the new demands you are placing on it. Eventually, it looks easier and faster to rebuild the software with an updated architecture, than to continue working with the old code.

Here are the three major options:

1) Standard Approach - Prototype and expand

The standard approach is to build a prototype of the new product, and then expand it into a complete application.

Advantages:
This approach has the advantage of being relatively cost efficient. During the prototyping phase, you can work with a very small team, or even your best individual architect. And, you can make significant changes to build the product you actually want.

Disadvantages:
The start of the project might be delayed by work on specification, to ensure that the important details of the old product make their way into the new product. And, it's risky. Once you commit to expanding the prototype into a complete application, you enter a potentially long period in which you are spending extra money on development, and you do not have an up-to-date product. In the worst case, you have a situation like the one faced by Microsoft when they release a new operating system, where the new product needs to do everything the old product did, or it will break customer installations. You could hold your breath for a long time waiting for this to happen.

2) Incremental

In the incremental approach, you replace big components of your software with more modern components, or you refactor the existing code. However, you do this in a series of steps that leave you with a releasable and saleable product after each step. This is often compared to "rebuilding the plane in the air".

Advantages:
The big payoff is that you have a much lower risk of ending up without an updated product. A more subtle advantage is that you don't need to do as much specification, if you are willing to say that the new product should do basically what the old product did. That saves you time.

Disadvantages:
Compared with building software from scratch, this is more complicated to do, and it takes longer. You are working with a larger codebase, and you have to figure out how to keep the plane flying while you rip off the engines.

3) Buy

You might be able to acquire the rights to something that does most of what you need to do (see my story). In an open source world, you might be able to take something off the shelf and adapt it. In fact, modern product rebuild plans almost always contain a significant component of buying or borrowing from open source. As the amount of software in the world grows, it's increasingly important to do research to find out what you can acquire or adopt.

Advantages:
Much faster, and probably cheaper.

Disadvantages:
Might not meet all requirements. Might place some restrictions on the ultimate value of the asset.

In this case, we decided on the "Incremental" option. The team was able to come up with an amazing plan in which every aspect of the architecture was replaced, but an existing application would still run correctly at each step. If you find yourself contemplating a rebuild, the reduction in risk from the incremental approach is so great that is worth applying your best brainpower to figuring out how to do it.