The first question you may have in reading the title to this post is what is a Brownfield application? The book opens up a discussion on this topic with this opening line:
“An industrial Brownfield is a commercial site contaminated by hazardous waste that has the potential to be reused once it’s cleaned up. To a software developer, a Brownfield Application is an existing project, or codebase, that may be contaminated by poor practices, structure, and design but which has the potential to be revived through comprehensive and directed refactoring.”
I was able to review the book “Brownfield Application Development in .NET” very early on in it’s creation. I am now the technical reviewer for the final stretch of this project.
I have to say up front that I never considered myself a Brownfield application enthusiast in the least! I didn’t really even know that a Brownfield application as defined above actually had a name other than FUBAR. And to be quite honest the whole concept of a Brownfield applications is something that I have always tried to avoid. However, after having read this book a few times I must say that while I don’t consider myself a Brownfield developer I think we all come across them and interact with them more often than we might think. While not wanting to identify with the Brownfield developer myself…I have to swallow the lump at the back of my throat and admit that we are all Brownfield developers from time to time during our careers.
We have all heard the expression that code not under test is legacy code and have all worked on code bases without tests.
We have all probably been to a dev shop that didn’t have proper source control.
We have all seen deployment processes that require all hands to be on deck in the wee hours of the night to push and pull and tweak the code through to production.
If any of these statements ring a bell with you (and probably many other examples as well) then you have been involved with a so-called Brownfield project.
If you are anything like me, you probably show up to the first day of work at a new contract and find at least one “are you serious?” feature of your new work environment in the first 30 minutes to an hour…with many more that follow closely behind. If you are anything like me you see problems…sure…but you also know that there is a better solution or an industry standard way of dealing with each and every one of those problems.
This book does a great job of not only laying out a road map for locating each of the various types of pain points offered by a Brownfield application but it also does a great job of suggesting how to deal with each of those pain points. And while the book is entitled “Brownfield Application Development in .NET”, don’t think that this book only deals with the technical side of this problem. It does a great job of covering all the aspects of these sorts of problematic applications and the culture and company that is ultimately responsible for allowing them to be created in the first place.
This book offers up ways to deal with some of the political aspects of fixing this type of application. It provides suggestions for how to deal with the people on these types of projects. Rules around broken builds are provided. A definition of what a “check in dance” is and how it changes when an additional feature is added to the big picture. And of course many of the tools that are out there to deal with these sorts of problems are covered too.
Here is a great blurb from the book:
“Maintenance of the application does not begin once it has been released into production. From a developer’s perspective, each line of code you write enters maintenance mode immediately after it is written.”
And then you have lines such as this:
“Then words like “spaghetti” and “minefield” start to enter the project’s lexicon.”
Whether this topic is old hat to you, or something that you have never thought of I find that this book is very easy to read and quite clear when making it’s points. I will share more as I read more. I really can’t wait for this book to be published. I think that this is going to be one of those books that every developer and software shop should own. It clearly defines what should be required by our industry…but rarely is.
