Brownfield development isn't so bad

Brownfield development tends to have negative connotations (after all, who wants to tend a dying/dead field?).

Another way to look at this though is that it is merely fall/winter. Despite appearances, perhaps we can make this field prosperous again.

What is brownfield really?

Not legacy.

I immediately think of a system from a different team1, littered with architectural issues. At first blush, it may look like a project that no one in their right minds would want to pick up. You may flirt with idea of doing a full rewrite.

Be fearless

To be successful you need to grok the system 2. Doing so enables you to be fearless to change it.

Refactoring a system you understand can be difficult enough. The prospect of refactoring one you don’t understand can be terrifying.

Be agile

You probably won’t be able to make all the changes you would like to see overnight. Like any other product, you need to prioritize and execute.

A recent example

The current product I’ve been working on was originally built by an external firm. The emphasis was not on maintainability or testability. In the end, the system manifested as a single ASP.NET MVC project. For a simple project, this is fine - but we’re talking about tax compliance and it is never that simple. Rules engine(s), complex object graphs, tax return generation all living in one web project doesn’t really make sense in the long run. A completely static repository “layer” also made things difficult to test (this practice seemed to be in vogue for awhile - this is not the first product I have picked up with this pattern).

After looking through the system for a day or so, I felt pretty confident in the technical approach:

  1. Introduce IoC (Autofac in this case)
  2. Pull EntityFramework out of the MVC project
  3. Introduce new Service layer for new functionality (emphasis on creating testability/maintainability)
  4. Pull Repository classes out of the MVC project as required by 3.
  5. goto 3

As we pulled more and more of the Service/Repository layer out of the MVC application, the effects spread. If you’re familiar, this is basically the approach of the StranglerApplication. That said, we just went for it - over the course of a sprint or two we refactored a good 60-80% of the code.

So now we have a “reasonable” backend. Now we have a new problem: the frontend! All of that gloriously global scoped Javascript (jQuery) and bloated components.

Remember, the absence of problems is not progress. Progress if the presence of new problems!


  1. I think “a different team” really means “a different time” in most cases. [return]
  2. This is the danger of letting a monolith live too long. It becomes nearly impossible to have a deep understanding of all the interrelated parts. Also not surprising that all of the brownfield projects I’ve worked on have this same problem. [return]