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 actu

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.