The Perils of Rewrites
As a firm that specializes in software engineering, MojoTech is often called upon to completely replace an existing product. Sometimes it’s because the old version has accumulated so much technical debt that it’s easier to start over than to press forward. Other times, the purpose of the product is changing so drastically that extending the old code to do the new job is a case of a square peg and a round hole.
Either way, we arrive at what we call a “rewrite”. MojoTech has done quite a few of these, enough to know our way around some of the pitfalls and psychological hobgoblins that tend to haunt such projects.
The most important thing to keep in mind is:
Just because it’s a rewrite, doesn’t mean you get to take any shortcuts.
The allure of “using how it works today” as a partial specification is intoxicating. Properly specifying a software project takes a lot of time and a lot of work, and the work continues throughout the life of the project. It would be really nice if a big chunk of that were already done for us. There’s a functioning application sitting there just begging to be copied, so we can get on to the “interesting part” — the new stuff!
Unfortunately, using “exactly how the old one works” as part of a specification is never the right move.
“No man ever steps in the same river twice, for it’s not the same river and he’s not the same man.”
Consider some of the things you inherit when using the obsolete version of a product as a form of specification:
- All of the wishes for how it was supposed to work. Many of these decisions were no doubt based on circumstances that no longer apply.
- All of the compromises that were made between the original implementors and the original sponsors. These are likely to be more prevalent than you might think and stem from technical considerations that don’t matter anymore.
- All of the “dark corners” of the existing application that may be unknown to the sponsor of the rewrite.
About “Dark Corners”: If the original app has been around for a while, chances are that no single person is capable of describing everything that it does. So, if you describe your new application as “everything the old one did, plus x, y, and z,” you are very likely committing to doing a lot more than you signed up for. As the sponsor of the rewrite, you may not be aware of some functionality, but that doesn’t necessarily mean that the features can safely be thrown away! When the dark corner is revealed, sometimes everyone realizes that the product actually can’t be replaced without re-exploring the same dark corner (or at least, thinking about the problem again and solving it in a different way).
Even if your existing application has none of these “dark corners”, there’s a more fundamental reason not to follow the shortcut…
If you always practice questioning your assumptions, your life will improve.
As product managers and as engineers, we are at our most powerful when we have the ability to step back and think about different ways to solve a problem. Magic happens when you are able to hang onto your ability to question assumptions. Many times, there really is a better, simpler way achieve what needs to be done, and the livelihood of the project depends on someone finding it.
Even better, the more you stay in the habit of seeking these moments of inspiring simplification, the more readily you will find them. You should aspire to cultivate the will to reflect, and you should encourage your people to apply their own individual intelligence and perspective to their toil, all of the time!
Using “because that’s the way it already is” as a basis for the requirements of a project is poison to this regimen. “Everything another product does”, as a concept to be adopted as the basis for a new product, does not lend itself well to intelligent reshaping. It’s simply too monolithic and inarticulate to be dissected. Thus, following this sort of “shortcut” will drastically limit your ability to apply cleverness towards your true strategic goals.
The good news is…
Rewrites can work. But, they only work when you respect the requirements gathering and feature management aspects of the project. Start at the beginning and think about everything that your replacement product should do. Give your rewrite a chance to surprise you!