Jargon, slang, blah blah blah… So what’s the difference between the two? Its quite simple actually, so lets dive right into it.
Greenfield Development
Greenfield Development happens when you start a brand new project, as in, clean slate development. No legacy code lying around, no old development to maintain. You’re starting afresh, from scratch, from a blank slate, with no restrictions on what you’re doing (other than business rules of course).
The definition from the Wikipedia Entry states: "In software engineering jargon, a greenfield is a project which lacks any constraints imposed by prior work."
It’s also described as "File –> New Project/Solution".
In my experience, a true Greenfield projects is quite rare in line of business applications. Almost always you have to interact with some legacy code at some point in time and perform integrations with that legacy code that impose limitations on your development.
Examples of Greenfield Development
- Building a new E-commerce solution from the ground up
- Implementing a new rules engine for your company from the ground up.
- Rewriting an old app in a new language (maybe C++ to C#) but not utilizing any of the old code other than for business rule reference
- A new startup wants application X Built. Application X has never been built before, therefore Application X is a greeenfield endeavor
Brownfield Development
Brownfield Development happens when business decide to develop/improve upon an existing application infrastructure. As an upgrade is implemented into an existing solution, the development is said to be Brownfield.
The Manning "Brownfield Application Development in .NET" book defines Brownfield development as: "A Brownfield application is a project, or codebase, that was previously created and may be contaminated by poor practices, structure, and design but has the potential to be revived through comprehensive and directed refactoring."
I’m not sure if if completely agree with the definition above, but I do think its close. Brownfield Software Development is about working with previously created code. To me, it does not mean that the code is legacy, as the term "legacy code" has a completely different connotation as soon as you’ve read Feathers "Working Effectively with Legacy Code". I believe Brownfield development can occur on an excellent foundation of code. What if the application that we need to enhance has 90% code coverage? Does that mean that the code is poorly structured and hard to update, and contaminated? No, not at all. I’d argue that it doesn’t have a contaminated structure with that much code coverage, but then again, it depends on the code and how it was architected.
Examples of Brownfield Development
- Adding a new feature to software that was developed last year
- Altering the functionality of the code to enhance the performance of an application
- Upgrading the codebase to expand the working set of functionality across the board.
Conclusion
My experience in the field varies between Greenfield and Brownfield. I’ve spend 1/2 my career behind the desk at companies as an employee. I’ve spent the other 1/2 as a consultant. I’ve seen quite a few Greenfield projects, and I’ve seen even more Brownfield developments. As a standard employee at any company, I’d say that 50% of what I did was Greenfield (and I know that’s not normal from talking to my colleagues), and 50% was Brownfield. From a consultant standpoint, I normally perform Greenfield development. But as of lately I’ve been on a Brownfield engagement that’s spanned many months. I’d have to say at this point in time I’m doing about 70% Greenfield and 30% Brownfield as a consultant.
What’s the norm? I can’t say, I’m no governing source of this info, but from what I’ve seen in the field it looks like to be ~20% Greenfield and ~80 Brownfield.
Does it matter which type of development you’re involved with? Yes and No. If you want to make great software, you can do that in both areas. If you want to run with the latest and greatest technology in the field, perhaps you should consult a little more. But in the end, what really matters is that you have passion for what you do regardless of the type of development you’re doing.
Useful post.
Also in my point of view every software project that is green field will be brown field soon. you cannot find any successful software project that is not brown fielded very quickly! Some developers around me think that working on brown field projects is down grading as software developer.
“Jargon, slang, blah blah blah” about sums it up. It seems like the industry enjoys making up new, arbitrary terms for old, simple, universally understood concepts just so that prospective employees can look stupid when they get asked about it during an interview.
It remind me this:
Any code of your own that you have not looked at for six or more months might as well have been written by someone else. Eagleson’s law