Bruno Miranda's Notebook

Have you ever second guessed yourself when talking about rewriting a large piece of software? Most will argue that rewrites are a bad idea. Usually these initiatives are chosen to remedy software that is full of technical debt, or when unnecessary or half implemented functionality composed the majority of the code-base.

In my opinion rewriting a piece of software is awesome, it gives you a chance to start fresh. Why so many advise against it? Because you must first fix the root cause. The reason you have technical debt is almost always because of a broken process. The reason you implemented something that no one will ever use is almost always related to poor business owner <-> developer communication. If you don’t fix the process before you rewrite, you will end up with yet another technical-debt filled application. Your team members will certainly be more frustrated. Stakeholders and managers may lose faith and your life may continue to be a living hell.

Fix your process, then fix your your code. Implement a process that makes sense, which is not always easy to follow. Make sure you follow it. Stay as close as possible to the business owner, he who holds the keys to the application’s features and their acceptance criteria.

Albeit somewhat obvious, avoid the “cave mode” like the bubonic plague. Software writing should be an open process between stakeholders and development team. Gather feedback early, make sure you are on the right path. Don’t assume you are in the right path. It is better to know you are on the wrong path than to think you are doing it right.

There is no conclusion to this post, as software processes are ever-evolving, so are the conversations about them.

Remedy before you go bananas.