Our title "Brownfield vs. Greenfield" may initially read like a fictitious court case but what we're really talking about are the two classes of software projects: A brand new product/app/code vs. rewriting/adapting an existing product. (Although the focus of this link is a guide to young software developers, this definition of the issue is pretty good.)

Oftentimes, you don't really "choose" between the two. If you have an existing system or product and it's functioning relatively ok, then building onto or fixing the existing code (brown field) is a no brainer. Similarly, you may have a brand-new feature, function or product that does not exist in your company before (e.g. adding an online chat help system when you did not have one before, a new interface between two of your existing apps, etc.) then the work by its nature will be all new (green field). Generally, rewrite or addition projects are more common than all new code projects - if we create an app and then we have upgraded releases 15 times, then that's 1 green field project and 15 brown field projects.

Here at Plannedscape, on the last 10 projects of ours we've had, 3 of them were brand new, 5 were clearly rewrites/fixes but we also had 2 that would be a grey area of both green and brown (technically if you mix the colors green and brown, you still basically have brown). On those jobs, we have been creating new features, but alongside previous code and using the same framework, references and common functions. But that's neither here nor there.

So how does this relate to your business? When do you have to make a decision? If your current codebase and solutions are solid, then adding to it (brown field) is a no-brainer. Unfortunately, these judgement calls are usually when your existing code is troublesome, or worse. When the development team is the same as for previous versions of a product, those very developers are naturally motivated to say that they did a great job the first time, so the recommendation is to stick with the same foundation and build onto it - no matter what the reality is. It takes both honest, pragmatic developers and understanding management to sort of "start over". But when it's a new team or even just a replacement developer comes on, you often get a more honest assessment of what's going on. In our case, when we've been newly brought on to work with existing code, the reason we've been called in is that the previous programmers were not doing an adequate job. That's built into brownfield projects with a new software team.

One regular client of ours is a situation where we were brought in to provide project management tools and supervisory help for an existing in-house developer working on a complex app. Our initial code review told the company's management what they unfortunately already knew: the right thing to do was a full design of their product. This got them in that place where you don't want to be - needing a huge outlay of cash, planning and time to move forward. It's similar to the dilemma of how much work to put into repairing a used car vs. spending the money on a new one. These are tough discussions for a company to have. With this client, we ended up developing future plans for the new project, but meanwhile we are prioritizing small fixes to extend the current product lifecycle to bring in revenue for the company and for the future development. We really do love this client, but from years of going down the wrong development rabbit hole, they've put themselves in the position of being stuck in the middle with software not great enough to bring in enough money to justify future development and paradoxically needing more money to develop improved software. Everyone is doing what they can - stay tuned on this one.

Another case study of ours was on a potential project last year where they had a fully designed web site developed in India as a prototype and we were to "wire up" the backend, since all of their design was meant to display the data that our code would look up. This startup client had spent a lot of critical money and time on both the development of a database schema and their front-end design. In theory, this project could have been fine. But on our initial analysis we discovered that the web design and the database schema was completely unusable. This client had already been taken on a ride by their web developers. So when we bore the bad news that our strongest recommendation would be for them, us, everybody to start over (which obviously means more money to turn a brown field into a green one), they felt pot-committed and wanted to plow ahead with development with their current shaky foundation. It wasn't a crazy decision, it was based on limited resources (aka money) for this startup. We pulled out of the project; sometimes the smartest decisions we make here are about when to turn down a project. Still, we wish them luck.

Both of these examples show that time and money are the biggest factors into when and why going green field (starting anew with a clean slate) vs. brown field. We probably aren't breaking news here. That should be obvious.


(Click here to read Part 2 with some quick-hitting advice.)