When Greenfield Is The Solution To Brownfield

Not once but several times I have witnessed or had direct knowledge of Greenfield projects successfully replacing or improving Brownfield projects.

This would run counter to the general rule that Greenfield is not the solution to Brownfield. Both are true, which can be understood by realizing that these special cases will not generalize across all efforts. These special cases share one common characteristic. They accepted limitations and often tried to accomplished only one limited objective.

One effort that occurred at a company I worked at set out to merely reorder and make more sensible the object hierarchy common to all items. The actual functionality was not changed, just the implementation details. The language used was not changed. No new methodologies were introduced. The objective was limited and a success. A success even though it was late, because it actually did result in an improved product.

Why Greenfield Development Is Not The Solution To Your Brownfield

Facing a Brownfield project, the obvious solution is to start over. As a general rule this does not work. Which does not mean it cannot work in isolated instances.

Consider those Brownfield projects that are so bad you or your client are willing to abandon everything and start over and do it all again. There must be multiple problems in the Brownfield. These problems have probably reached an unworkable state. Working on one problem creates other problems. One problem prevents working on another problem. Perhaps the source code for a COM component has gone missing. (I do not know what it is about COM but since it's widespread use, every company seems to have a COM component with missing source). Or perhaps knowledge of the inner workings of the system is missing. Perhaps the original perpetrators of the code have fled the scene of the crime.

So the motivation for fixing the Brownfield is the ability to fix the multiple problems. This is also why the Greenfield approach will fail. You have a mandate to fix everything in the Brownfield. But this is too much to be attempted at once.

It is not that you can not fix each of the problems in isolation. It is the combination of problems makes it exponentially more difficult. If lack of knowledge (like missing source code or fled perpetrators) is added to the mix, you will be flying blind. You may think you know what the component is supposed to do but there is tribal knowledge embedded in the source code.

But lets suppose you have jumped off and started the Greenfield to fix your Brownfield. As you solve the problems, the solutions will start to compete with each other and to a certain extent some hard trade offs will emerge. Some of these trade offs are what caused the original nest of problems in the original Brownfield. Thus the Greenfield becomes a Brownfield.

So it then becomes a race. Can you get all of the features implemented in the new Brownfield before being overwhelmed by the toxins being created.

Buzzword: Greenfield Brownfield

It has become common to refer to new development projects as Greenfield. This obviously conjures images of an untouched patch of land with no previous work impeding progress.

Of late, a new term Brownfield  has become trendy to describe the rest of software development. Here there is the obvious contrast with Greenfield in the sense that the ground has been torn up and there is dirt and mud everywhere. But in addition, Brownfield had a prior meaning in commercial real estate. Brownfield referred to a property contaminated by one or more toxins.

In the case of software development, these toxins are prior decisions or implementations which have gone bad or never worked in the first place.