4 ms·

I used to work for a startup that rewrote its products all the time. It was a huge mess with all the consequences outlines in the article. The problem was not

by sp_ 16y ago

I used to work for a startup that rewrote its products all the time. It was a huge mess with all the consequences outlines in the article. The problem was not the rewriting itself but the lack of understanding how things went wrong the first time. From my experience it is absolutely mandatory to have many deeply introspective and self-critical thought sessions to figure out how you got into the mess. Only if you have clearly identified what went wrong in the past, you will be able to successfully rewrite a project and avoid the mistakes. For some of the products we did this and rewriting was a huge success. For some others we did not and the rewrite turned out to be just as terrible as the original version. Then we rewrote it again and it was still a mess.

caseysoftware 16y ago
Either way... the original problems don't just disappear. They're with you all along until you completely replace the product. And even then, they don't disappear. Windows 98 is 12+ years old and it's still lurking around out there. Vista was only the main version of Windows for 2 years and I bet it will haunt our support queues for another 5 years at least..
stcredzero 16y ago
For some of the products we did this and rewriting was a huge success. For some others we did not and the rewrite turned out to be just as terrible as the original version. Then we rewrote it again and it was still a mess. Assume you're going to get it wrong, and leave yourself an out. Often the cost of refactoring is much less than the cost of a rewrite. If this isn't the case, then I suggest you look at your language/toolset/coding standards. Is it possible to get yourself to the point where you no longer have to pay the cost of a complete rewrite? It might even be possible and worth doing a rewrite for the purpose of avoiding future rewrites. (And if you say this is like "a war to end wars," I'll just say that's cute, but wrong.) Was there ever a "Five Whys" asked about the rewrite?
- sp_ 16y ago
  The one product I was mostly involved in needed to be rewritten because it was the result of a quick proof of concept hack that kept growing because people actually bought it. There was literally no separation between GUI, model, or DB backend. Adding to the code was like swimming through molasses. I took the product over as lead developer and saw no way to save it. It helped that only maybe about 10% of the features we wanted to have were implemented, so two of us managed to do the rewrite in less than six months. The main focus of this rewrite was indeed to make sure that we would never have to rewrite the product ever again. We kept a very close eye on identifying what went wrong, what design principles can help us to avoid doing things wrong in the future, and how to design for extensibility considering that 90% of the features still have to be added. In the end the rewrite turned out to be very successful. Until the day I left the company (three years after) no rewrite was ever necessary again. Rather, we managed to keep up the good principles laid down during the rewrite so we could just work on the code incrementally. The product was also the commercially most successful piece of software the startup sold.
  - stcredzero 16y ago
    Yay! Sometimes sanity wins!

by sp_ 16y ago

caseysoftware 16y ago

Either way... the original problems don't just disappear. They're with you all along until you completely replace the product. And even then, they don't disappear. Windows 98 is 12+ years old and it's still lurking around out there. Vista was only the main version of Windows for 2 years and I bet it will haunt our support queues for another 5 years at least..

stcredzero 16y ago

For some of the products we did this and rewriting was a huge success. For some others we did not and the rewrite turned out to be just as terrible as the original version. Then we rewrote it again and it was still a mess. Assume you're going to get it wrong, and leave yourself an out. Often the cost of refactoring is much less than the cost of a rewrite. If this isn't the case, then I suggest you look at your language/toolset/coding standards. Is it possible to get yourself to the point where you no longer have to pay the cost of a complete rewrite? It might even be possible and worth doing a rewrite for the purpose of avoiding future rewrites. (And if you say this is like "a war to end wars," I'll just say that's cute, but wrong.) Was there ever a "Five Whys" asked about the rewrite?

sp_ 16y ago
The one product I was mostly involved in needed to be rewritten because it was the result of a quick proof of concept hack that kept growing because people actually bought it. There was literally no separation between GUI, model, or DB backend. Adding to the code was like swimming through molasses. I took the product over as lead developer and saw no way to save it. It helped that only maybe about 10% of the features we wanted to have were implemented, so two of us managed to do the rewrite in less than six months. The main focus of this rewrite was indeed to make sure that we would never have to rewrite the product ever again. We kept a very close eye on identifying what went wrong, what design principles can help us to avoid doing things wrong in the future, and how to design for extensibility considering that 90% of the features still have to be added. In the end the rewrite turned out to be very successful. Until the day I left the company (three years after) no rewrite was ever necessary again. Rather, we managed to keep up the good principles laid down during the rewrite so we could just work on the code incrementally. The product was also the commercially most successful piece of software the startup sold.
- stcredzero 16y ago
  Yay! Sometimes sanity wins!