Thoughts On: How To Survive a Ground-Up Software Rewrite Without Losing Your Sanity

Earlier today I came across this awesome post How To Survive a Ground-Up Rewrite Without Losing Your Sanity aka: Screw you Joel Spolsky, We’re Rewriting It From Scratch!

There are 3 main takeaways from this article I believe.

• Avoid from scratch system re-writes, I mean try to avoid the problems that may lead to requiring a re-write. Easier said than done.
• Structure your software and systems such that you have the best chance to re-work a small piece at a time and deliver into production - separation of concerns.
• Make absolutely sure that you define the business value (stuff that’s useful to the business) for any re-write and that the project is structured in such a way that you start delivering value as early as possible along the way.

I could immediately identify with this. In 2009 we embarked on a complete system re-write. This article made me realise several things; this decision to re-write was correct, that we had gone about it the correct way (although we had never done a re-write before), and ever since we have been making every effort to ensure a complete from scratch system re-write isn’t ever required. Rather the software and systems are structured in such a way that change can happen incrementally. I’m not trying to say we are perfect, far from it, but I believe we are in a good position.

However there are some other vital ingredients that we should mention; awesome software engineers, a good engineering culture, phylosophy, and methodology. The Joel Test and The Rands Test cover these aspects.

Finally I think some of the points covered in this post actually apply to any software project. Make sure the business value is defined and value is delivered as soon as possible - Minimum viable product comes to mind.

Happy coding!