Don’t Rewrite, Refactor: Why Brownfield Development Works
Originally posted on MediumDon’t Rewrite, Refactor: Why Brownfield Development Helps
If you’re new to brownfield development, here’s a primer.
According to Wikipedia:
Brownfield development is a term commonly used in the IT industry to describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing (legacy) software applications/systems.
All software ages poorly.
All successful software becomes legacy software and the architectural decisions taken while building the existing software may not always be in line with what is current or appropriate to the new business and technological environment. While a large part of the current literature on software development seems to focus on building new systems, they rarely talk about interfacing or transforming old systems into new systems.
It is not uncommon for many development teams that have been evaluating legacy software to rewrite it.
While it is important to continuously improve on a given codebase to adapt to business needs, if poorly done, this can result in a duct tape-based architecture and a lot of spaghetti code.
Some development teams, when faced with such a codebase, will simply choose to rewrite the existing system from scratch. While it may be justified at times, it is rarely a good idea to rewrite an entire system.
It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.
The following reasons often motivate a rewrite.
- New feature development becomes hard and complicated to ship
- The system seems very brittle, and there are bugs and regressions
- The performance has significantly degraded and the old architecture simply cannot handle the scale.
The first reason is often the most common one for why people want to rewrite an existing system.
A case for embracing complexity
But rather than rewriting, our solution is often to spend time reading the existing code and refactoring it.
It may be that the database models are building HTML or JSON strings, or the view code is making calls to a web service or sending emails. Or it could be that the code has been copy-pasted everywhere with minor modifications, making it buggy and error-prone to maintain.
These are mostly business needs implemented poorly and have resulted in technical debt in the system. And as with any debt, technical debt can give you leverage in the short run, but if left unpaid, cost a lot more to pay it back.
At Tarka Labs, we constantly refactor our code.
Refactoring is not the same as rewriting. The scope for refactoring is often a lot smaller and targets a particular feature or a workflow or a subsystem. We spend time studying the existing codebase and identify the problems with it. We then come up with a game plan on how we can modularize or bring in seams to the existing codebase.
These seams are important as they define the boundaries within a system and can be individually tested. We then write a test harness for the expected functionality and refactor the existing codebase and build something better.