Greenfield and brownfield software development are two different approaches to creating software, selected on the basis of the condition the project is in when we step on board.
The terms ‘greenfield’ and ‘brownfield’ are used in many industries besides IT, deriving their meaning from physical real estate development.
The meaning is similar across domains: greenfield describes new builds on undisturbed terrain, while brownfield refers to the continuation of existing projects or rebuilds on the site of older developments.
For this reason, brownfield often indicates some type of damage or contamination which can make completing the project more challenging. In real estate, this could be hazardous building materials such as asbestos left over from recently-demolished buildings at the site; for us in software development it can mean legacy code that’s difficult to work with or required integrations that call for additional effort.
The difference between greenfield and brownfield software development is crucial when determining the approach to a project; treating a midstream project as unspoilt ground, or assuming anything will be in place in a greenfield project, can upend expectations, disorder planning and uproot execution. So let’s examine the difference more closely.
Greenfield vs. Brownfield
Greenfield and brownfield sites require totally different approaches from a software company.
For us, a greenfield project is one where we’re developing a brand new software application in a ‘place’ in the company where nothing’s ever been before. A retail company that’s moving into ecommerce for the first time, or a publisher that’s building out a true digital presence, would be greenfield sites: we’d be building an ecommerce solution or a CMS completely from scratch. That means we have to do all the work, but it also means we get to choose how. We can select the most appropriate stack, identify the best tools and create exactly the product we want, without reference to anything but the client’s needs. The road is clear and straight, but we have to build it all ourselves.
That’s often a lot less work than a brownfield project. Brownfield projects, remember, are those where someone has already done some of the work, or where we step on board to replace an extant application that’s not functioning sufficiently well.
What this means, of course, is that we have to make very careful decisions about what to demolish, what to keep and what to replace — just as developers do in the world of real estate. Where they have connections to the water, transportation and power grids to consider, we have to think about integrations with the rest of your stack.
We have to check that when we rebuild your application we don’t blow up your APIs and have to hunt through them and fix them so you can continue to provide mission-critical services to your clients. A significant amount of research and preparation has to be done to make sure we don’t do the coding equivalent of pulling out the H-beam that’s holding up the roof.
For these reasons, we approach greenfield and brownfield projects differently. At AndPlus, a greenfield project means we start from the ground up with the discovery and scoping process and help to strategize the appropriate technologies and design aspects. We create an agile backlog and plan for the creation of a minimum viable product (MVP), develop the working version and put it to the test. After that we work on developing new iterations to resolve operational issues identified in testing, and when we have a final product we plan for the launch. We also provide support to the customer after launching, until they are fully at ease using the new software product.
A brownfield project, however, begins with an end-to-end code audit for us to gather a full understanding of the basis from which we are building. We provide an in-depth report from our engineering and QA teams and host a code review. This research gives us the information we need to determine the future path of the project to take the unfinished software to a point of completion. Although the execution depends on our findings, typical brownfield projects involve continuing to work with the current technologies already in play and allow our engineers to find ways to deliver the required solution. This often means salvaging previously written code and starting over from a specific “checkpoint” in the project. We then insert the code into our Agile process and turn the unfinished software into an impressive application.
Listen to me chat about Brownfield vs Greenfield projects on our podcast below!
Benefits and Disadvantages
Each approach has benefits and drawbacks, for both developers and clients.
Advantages of greenfield software development
- Opportunity to build from the ground up with state-of-the-art tech and best practices
- A clean slate for software development, including matching every stage of the product with business goals and requirements — we can build for where you want to be, and give you a product that helps you get there
- No requirement to work within the constraints of existing software, code, systems or infrastructure
- No dependencies or ties to existing software, partners or business processes
Disadvantages of greenfield software development
- Can be riskier, because you’re making all the decisions — there are no trammels but no scaffolding either
- More up-front investment of time and energy, because the scope and purpose require analysis, research and definition
- Different experience and skills are required from brownfield development: you need developers who can match business needs with software tools without external guidance
- Many stakeholders are involved, since the project goes beyond development alone; therefore, getting buy-in and consensus can be more difficult, and the project can move slower, especially to begin
The main disadvantage of this type of project is high capital investment, which is more often required for the hardware needed to use the application than for the software development itself. The project scope needs to be very carefully mapped out to align with the company’s business goals and avoid scope changes during the project.
Examples of greenfield software development projects include:
- Developing a new eCommerce solution for a company that hasn’t used one before.
- Rewriting an old software program in a new language, without using any of the old code except for referencing business rules.
- Building a brand new application to execute tasks that have never been done before.
Advantages of brownfield software development
- Offers a set place to start and a predetermined direction — developers are aware of the dimensions of the space they have to fill, so to speak
- Efficiency: careful alterations and additions to existing code can deliver disproportionate benefits
- Can be done within existing, defined business processes and technology solutions
- Allows reuse of existing code
Disadvantages of brownfield software development
- Existing environment may require significant re-engineering to match new business requirements: this may approach or even exceed the difficulty of building from scratch, though it often does not
- Requires a different type of skill and experience from greenfield development: developers must know how to build within existing constraints and must develop a thorough knowledge of existing systems, services and data
- Requires a detailed and precise understanding of the potential and constraints of existing business processes and technology as it actually operates, not merely in theory
- Dealing with legacy code can slow down development and add to overall development costs, particularly if the code is quixotic, specialized or of poor initial quality or legibility
Brownfield projects often benefit financially from the incorporation of legacy code and systems, which reduces the investment needed to accommodate the new software. This same factor can be a disadvantage, however, by preventing developers from using optimum flexibility and efficiency of design.
Examples of brownfield projects include:
- Incorporating new features into software previously developed and implemented
- Revising the code to increase its functionality, which can enhance the way an application performs
- Updating the codebase to generally increase the program’s functionality and enable it to undertake a wider range of tasks, improve speed of execution or deliver more comprehensive results
Making the Decision
The decision doesn’t have to be binary. In many cases, the same goal can be achieved by a hybrid approach that ‘greenfields’ the elements that best reward innovation and ‘brownfielding’ the rest. Where a business really does have to choose one or the other, it’s necessary to consider a number of variables.
These include current and future labor costs and availability, economic incentives, and grant funding available for specific types of initiatives. Evaluate these against the projected product to determine ROI and consult at length with a reputable development company to help you make a final decision on which to choose.
Many half-baked projects were abandoned as a result of poor planning and execution, but because of the capital investment the clients prefer to try resurrecting them than starting fresh. Having said that, brownfield projects can still work out remarkably well using an Agile process and an experienced team of software engineers. Provided the code is not poorly structured, contaminated or hard to update, it’s possible to turn a discarded project into a thing of beauty and a joy forever.
Interested in working alongside AndPlus on one of your projects? Whether greenfield, brownfield or something in between, we can help.
