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 successful software becomes legacy software and the architectural decisions taken while building the existing software may not always be inline with what is current or appropriate to the new business and technological environment. And in general, software ages pretty poorly. 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 for business needs, if poorly done, this can result in a duct tape based architecure and a lot of sphagetti 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. - Joel Spolsky
We see the following reasons that would motivate a rewrite.
- Very hard to adapt or ship new features
- The system seems very brittle there are bugs and regressions
- The performance has significantly degraded and the old architecture simply cannot handle the scale.
We see that the first reason is by far the most common reason why people want to rewrite an existing system. Rather than rewriting, our solution is often to spend time reading the existing code and refactoring it rather than rewriting 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. They are mostly business needs implemented poorly and have resulted in technical debt in the system. As with any debt, technical debt can give you leverage in the short run but if left unpaid, it costs a lot more to pay it back later.
At Tarka Labs, we constantly refactor our code. Refactoring is not the same as rewriting. Refactoring's scope 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 to something better.