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?
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.
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.
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:
- 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)
Repositoryclasses out of the MVC project as required by 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.
Remember, the absence of problems is not progress. Progress if the presence of new problems!
- I think “a different team” really means “a different time” in most cases. [return]
- 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]