Tony Patton lists reasons why proposing a code rewrite might make sense, though he warns that building a new system is risky.
During the tour portion of an interview a few years ago, I was shown the heart of the business where operations staff used a .NET-based application that was being used on a daily basis, and the company was very profitable. During the technical portion of the interview, I was told the person hired for the position would be working on a complete rewrite of the application. They seemed surprised when I asked why. The answer was simply their CIO wanted to use the latest .NET version and Microsoft products.
I never worked on that project, so there may have been more reasons than what I was told, but the one presented to me made no sense. Why scrap something that is working? This was the focus of a famous blog post that Joel Spolsky wrote years ago, and it continues to be a hot topic.
Pushing for a rewrite
Application developers are a finicky bunch that seemingly love to complain about the existing codebase and how they would do a complete rewrite if it was their decision. Starting from scratch seems like a good idea, but it isn't always that simple. There are usually four general categories of reasons when proposing a system rewrite.
- Performance issues: Problems with the daily functioning of a system are irritating and can directly impact the user base and could affect the business (and bottom line). These include slow web page load times, endless data processing time, database overload, and so forth.
- Buggy system: While bugs can have a direct correlation with performance, some bugs (e.g., a calendar popup control not working properly or inadequate error handling) are just a nuisance.
- Old technology: Most technology is relatively old when a solution is rolled out. I remember pushing a .NET 1.1-based application to production years ago with Microsoft unveiling .NET 2.0 around the time we went live. Application development is not a simple endeavor, so projects done properly will take time and, thus, may miss the latest and greatest release.
- Unorganized code: The methodology used in the past to build an application probably does not correlate with today's trends. For instance, the agile movement and Test-Driven Development were not widely embraced until recently, so do not expect such an approach to be part of an older codebase.
It is often the case that all four reasons (and more) are listed when making the case for a rewrite. With that said, is a complete system rewrite necessary to address these issues, and are there guarantees that similar problems will not exist in the new product?
Tracking bugs and performance
Last year I tracked a performance problem to a SQL Server cache setting; once it was changed, the problem vanished, but an issue with web page load times surfaced. We methodically tracked and investigated issues until system performance was acceptable end-to-end. A total rewrite may have not had the same issues, but there would likely be other issues.
Unfortunately, troubleshooting issues and bugs often introduces finger-pointing where one team says it is another team's fault (depending on the size of the organization). The previously mentioned issue is a good example where the web developer blamed the database and the DBA blamed the application code. Of course, application issues were discovered, but only after the database issue was resolved. Whether working on production issues or building a new system, there needs to be a close partnership between teams (development, DBA, quality assurance, business stakeholders, etc.), resulting in a consensus on how things should work. Good working relationships expedite troubleshooting.
Bugs are a part of every application, whether it is a legacy system that has been in production for years or a brand new application. A good issue tracking system and necessary product patches can address these as needed. The continuous development approach means these bugs are fixed at a rapid pace. A complete system rewrite will not avoid bugs, so using such bugs as the impetus behind a completely new product is not the best approach. You should focus on individual bugs and fix them as needed without impacting the rest of the system that is working as planned.
Always chasing the latest and greatest is a must for consultants who need to keep their skills sharp, but it is not a good way to build an application or run a business. A quick survey of various websites shows a large majority still use classic ASP and many more still are using table-based layouts in their web interfaces. Yes, these are older technologies, but they still get the job done, and there are plenty of developers available with the expertise to work with these technologies.
One caveat with older technology is it may be hard to find needed technical resources, and if you do locate someone they might charge a premium price to help. (This 2012 PC World article references a company that stills uses a punch card system.) I recently worked with a client with a 10-year-old web application built with classic ASP (along with plenty of ActiveX add-ons) that would not work on Windows Server 2003 or newer. This was a situation where an application rewrite was definitely a possibility, but I was able to redo a few pieces of the application to get it working on the new server. The client is working on a new version that adds much-needed features while targeting a newer platform.
A less-than-tidy codebase is a common problem for newer and legacy systems. Let's face it, all developers do not approach coding in the same way and often changes/updates are made at an alarming pace with no room for making things pretty (or legible). In addition to readability, common problems include code duplication, orphaned code, lack of unit tests, and more; these problems may cause maintenance headaches, but they do not necessitate a complete rewrite. Refactoring is a good place to start when looking at the code, and then documenting what it does and how it does it. However, dealing with an existing codebase means being careful to not break what is working; this is why many developers back away with raised hands when asked to clean up code.
Starting from scratch should be the last resort
The world is full of so-called bad and outdated code, but a lot of this code is at the heart of successful businesses. A system might have so many problems and does not fully meet the business needs that a complete rewrite is necessary, but oftentimes you can pinpoint and fix bugs and issues on a case-by-case basis along with adding new features as necessary. Existing systems have been fully tested as they are actually being used in production.
Taking on the task of building a new system is full of its own risks, so be absolutely certain when following that path.