|
As someone who has argued against a rewrite, lost the argument, and then proceeded to do the rewrite, I would push back strongly on the notion that we have a perfect specification, which is just "do what the old thing did".
This specification is woefully incomplete, of course, just as a vague requirements document for a brand new service or product is incomplete. When someone proposes a rewrite for software, I ask him or her to think critically along the following questions: 1) What is the purpose of the rewrite? What do you hope to accomplish by it? What business objectives are furthered by the rewrite? 2) Explain in detail what is wrong the the existing code base, and why it is untenable to fix those problems piecemeal. 3) Explain in detail how the rewrite will avoid, overcome, or improve significantly on all the problems mentioned in 2). In my most recent, case, and as I expect in many others, I couldn't convince anyone to engage on any of these questions. For 1), we were told that the org planned to build significant new features on the product and the rewrite will help. However, the company's priorities changed significantly even as the rewrite was just getting started. By the time I left the company, I was not aware of any short or long-term plans to continue adding functionality to the now-rewritten product. For 2), the level of detail was along the lines of "the code base is awful. I hate it!" And, that's about it. Question 3) is, of course, impossible to answer if you failed to answer 2). Failure to be able to answer these types of questions is also in my eyes a strong indicator that you don't understand the existing product very well. And why would we? The existing team that built the thing had all left by that point, which is, in my experience, the norm, not the outlier. It's normal for devs to build something for a few years and then peace out, either via an internal transfer to another team or a new job opportunity. I believe that much of software is knowledge acquisition, and much of the cost of software maintenance is in dealing with the failure to transfer and maintain acquired knowledge over time. Rewrites can be spurred by ignorance, and that same ignorance can lead to the rewrite taking much longer than expected. |