Preface

It’s not easy inheriting another team’s project. If you haven’t been in a situation like this already, clearly you’re new to the industry and we welcome you into our midst. Whether you join a project as a replacement or as an additional developer, it’s rare for someone to go through their entire career working solely on so-called “greenfield” applications (ones with no prior history). Even if you do start a greenfield project, it doesn’t take long before the application starts to show signs of contamination.

We’ve been on many projects in different stages of progress, and it’s the exception, rather than the rule, that you find strong coding practices or frictionless processes throughout the codebase. Instead there always seem to be glaring issues causing the team, and ultimately the project, massive amounts of pain. Usually the team has either become numb to the pain or everyone has become resigned to the fact that it “just has to be this way.” Having seen it so often and with so many of the same problems repeated, we decided that something needed to be said about it. Hence, the book before you.

When we first started to talk about the contents of the book, we were looking to define the types of applications that drove us to write. We knew that they definitely weren’t greenfield, but were they legacy? Both of us had read Michael Feathers’ Working Effectively with Legacy Code (Prentice Hall PTR, 2004) and decided that the style of project we’d encountered wasn’t fully described by his definition of legacy. After some time searching on Google and reading Wikipedia (http://en.wikipedia.org/wiki/Brownfield_land), we both decided the definition of brownfield as it pertained to land management was much closer than anything else we’d come up with:

[B]rownfield 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.

So we absconded with the term and set about trying to make the land management definition work for software development.

You should note two things about this book. First, although we decided to write within the confines of our brownfield terminology, all the practices, techniques, and tools mentioned in the book apply equally well to any project. Greenfield, brownfield, or legacy, we’ve used these techniques to help our teams succeed. Don’t be scared to use them on other types of projects. Without them, we’d probably have many more failed projects under our belts than we do now.

The second thing to note is that this book isn’t meant to be a definitive guide on tools or practices. We continually evolve both to fit the projects we’re on as well as to improve the skills we currently have. Just because you’ve read this book, don’t stop your quest to gain knowledge and challenge both your techniques and those that are believed to be conventional.

With those two caveats in mind, we present to you our thoughts on brownfield application development.