Brownfield development ain'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.

1. I immediately think of a system from a different team, 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 of 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:

Introduce IoC (Autofac in this case)
Pull EntityFramework out of the MVC project
Introduce new Service layer for new functionality (emphasis on creating testability/maintainability)
Pull Repository classes out of the MVC project as required by 3
Go to 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” back-end.

Now we have a new problem: the front-end! 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!