The diminishing returns of rewriting a system without the original authors

Choosing to rewrite an existing system is a big decision. It usually requires a project to reach a point where the technical debt is too much to deal with, or the technology is so ancient that the compentencies no longer exists. However, it can also come from an engineering team that have gone the wrong way, or chosen to rely on a technology that has become deprecated. This particular story is about the later case. It aims to illustrate the two most important takeaways: domain independence and tribal knowledge.

The case

The story goes as follows: a platform we were basing a larger system on was having a major update with a lot of breaking changes. This was going from an earlier DotNet version and basically jumping 8 years into the future. The system was a strategic priority as it was going to be a selling point going forward, so it had to be made ready for future sales. The original team, were working on specific implementations for different customers already. It was chosen to make a new team to build the upgraded version. It consisted primarily of people who had never worked on the system before except for the architect, who had other responsibilities too. The system was only 2 years old at this point, so the primary reason for the rewrite was to keep on the latest version of the underlying platform.

Tribal knowledge

With most of the team gone a lot of the tribal knowledge had been lost. A lot of the knowledge gained from interacting with the end users were no longer available to the new team. The existing design document just listed a way the system was, but not the reasons for it being that way. This caused a couple of the decision that were made to be reversed, as the new team did not want to make what seemed like obvious mistakes. They later discovered why the original choices were made. (It is important to emphasise that some changes were also for the better, but most were introducing problems)

In a particular case the solution that was chosen by the new team turned out to be the original solution made by the first team. It had however been redone to fit specific requirements from the end user. This ended up being a regression, which only a member of the original team could have pointed out.

Conclusion

When rewriting a system it is important to be aware of the advantages and disadvantages in the original solution. However, if the team doing the rewrite is not aware which is which, they will end up going the wrong way in some cases. This essentially causes the project to be an entirely new project, since they have to do the discovery of what works and what does not. The main takeaways is to keep the original team when doing rewrites. Alternatively consider all rewrites without the original team as new projects.