Almost two weeks ago, Chad Fowler has finished his article series “Big Rewrite”. He lies down the pitfalls of rewrite projects in a very amusing way. The first post is an overview how and why management and/or programmers are lured into rewriting an existing application. The usual factors include maintenance costs, stability and the inability to implement new features without breaking existing ones. The next logical step is to take either the software or the code as a spec. This has already been laid out as a way to disaster in “The mythical man month” by Frederick P. Brooks. First, making the newly written software “act like the old one” includes reproducing all the bugs and design errors the old project had. Why then rewrite? Second, the effort to extract the specification from the running program or the source code is always underestimated: the poor state the project is in has been the reason to rewrite it… Paired with the preceding problem comes the underestimation by staffing the project as an implementation without any innovation involved. This is obviously not what reality looks like, since both recreating the existing functionality and improving the design of the project are highly innovative tasks. The fourth article sports one key point in a rewrite project. Keep the feature creep out at all costs! – I guess the reasons behind this are clear. The Big Bang approach is to change from the current productive system to the rewritten one in one single step, the Big Bang. Clearly, this has inherently several pitfalls. The current system is a moving target, since it has to be maintained during the rewrite as well. It therefore can not serve its purpose as a specification. Then, the new system is probably cleaner by design but not all parts will match up in speed and robustness with the old ones. The results are often fatal. (In my opinion, if there is a chance to upgrade in a Big Bang, the product was not complex and hence the rewrite not necessary.) The post Justifications and Lies comes somewhat late in this series. It’s about what happens, if a justification for rewriting a product gets nailed down and find its ways into the specs. Not that there should be no justification but most of the time the effects can’t be measured in a decent way and hence the decision should be a strategic one, e.g. taking the abilities of new employees into account. Finally, the personnel is taken into account: since the more experienced users/programmers have to tend the store, i.e. maintaining the current program, the inexperienced respectively those who are unfamiliar are charged with the rewrite. They stand no chance to wiping out existing bugs they don’t know about and are likely to repeat the design errors (the first program wasn’t written by monkeys either). All in all, most of the time a big rewrite isn’t something worth the hassle…