Brownfield vs. Greenfield
Posted by Charlie Recksieck on 2019-08-15
aka Existing Code vs. Starting Over
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.
We would like to conclude with a little practical advice about these critical brown vs green decisions:
* Be Honest - Take a pragmatic look at the issues. Do you have enough money? What really is the current state of your existing software? Do you trust your programming team? Your management team? Most of all, don't fudge decisions and view things through the fantasy lens of "if everything goes right ..." If you get a $30k bid and a $5k bid on the same project - do you want to leap at the low bidder right away, or should you consider why the other company is saying $30k.
* Bring In A Consultant - This is the prime area where third-party consultants can be worth their weight in gold. They shouldn't really have a dog in the hunt, and they shouldn't be telling you what they think you want to hear. Consultants are paid to render an opinion. (I would be remiss if I didn't mention that we are available to consult on a project.) Also, us mentioning "consultant" doesn't mean that this always must be a large consulting or software firm. Do you have a brother-in-law or old college roommate who's in software? Take them to lunch or call them to describe what you're hearing from a potential developer, and they can tell you what their Spidey-senses are telling them.
* Listen To Your Clients - Make sure you're not wasting valuable resources on a flashy, pie-in-the-sky solution to a problem that doesn't exist. We've been brought in on two software products that are bloated and overbuilt. If your clients don't care about a feature, why should you? (Maybe you do anyway for various reasons, but at least ask yourself the question.)
* Buy Vs. Build? - Are you sure you know what's available on the market? Let's say your new project is adding an e-Commerce section to your website for the first time - you are surely aware of various places that can give you simple plug-ins. For whatever it is, make sure you do your due diligence to see what's out there for a cheap, easier solution.
* Triage - Prioritize your next several new projects. Get a timeline together and think them through, discuss them with your team. Perhaps one improvement makes more sense right now than an even more important new feature later.
* Work In Bite-Size Chunks - Unless a complete, green field overhaul needs to happen, break up your brown field work into simpler, smaller parts. Phase 1 going smoothly is always a great way to go into Phase 2.
Good luck, everybody!