Best practices in brownfield development

The wikipedia definition for the term 'brownfield is this : ''In the United States city planning jargon, brownfield land (or simply a brownfield) is land previously used for industrial purposes or certain commercial uses. The land may be contaminated by low concentrations of hazardous waste or pollution, and has the potential to be reused once it is cleaned up. Land that is more severely contaminated and has high concentrations of hazardous waste or pollution, such as a Superfund site, does not fall under the brownfield classification. Mothballed brownfields are properties which the owners are not willing to transfer or put to productive reuse.[2]' .

I couldn't agreed more with this definition, especially about the hazardous waste and pollution parts. Brownfield development in software industry is very common, rarely a developer will develop a system from scratch without dealing with legacy code and applications.

In my opinion brownfield development is hard, and understudied. Every book on software development teaches how to develop a green field project, e.g. a project developed from scratch. Which is good. But no one is taught the essential skills and practices of brownfield development.

And that hurts. Very much.

What are the problems associated with brownfield development? They are many and varied and depend on both technical and human reasons:

• Lack of understanding on the underlying reasons why a technical solution was chooses to solve a particular problem.


• Lack of any legacy technical documentation and tests.


• Developers think they know the 'only right way' to develop software.


• Fear and uncertainty of breaking existing, working functionality.

When working on brownfield project I've found the following to be true and very helpful and productive:

Do not try to re-engineering the project when implementing new functionality, when the time comes that will be the only thing you will be doing. That way your will not bog down on useless, defect prone work.

• Do it as the other guy, use the same existing infrastructure and follow the same development principles. That way you will not add competing solutions and will achieve a homogeneous environment.



• Write a short, concise documentation for each feature you develop. That way everybody will know what you have done and why.



• Document key technical solution and practices in the project. Some problems and questions keep reappearing over and over. That way you will save everyone the time and effort of figuring them by them selves.



• Write smoke tests (functional or unit) for the core functionality of the project. That way you will always know if the core works or not.

The goal here is to not increase needlessly the complexity of the system, to save time and effort and to quickly gain the core knowledge the other guys had. If the client wanted you to re-engineer their system they would have hired you for that specific goal. It is often better to follow existing practices and procedures than to try to reinvent the wheel and fall in a bottomless pit of defects keeping popping up and deadlines never met.