Brownfield and Greenfield in software development

Software development is a complex project, especially if we work with something more complicated than just a simple CRUD application. If we want to cover a lot of business needs, we will have more and more requirements, new dilemmas, new use-cases and also a lot of things to monitor and check. Today I want to write about two project types: Greenfield and Brownfield. The fun fact is that nomenclature is from architectural business… and I work with software for architectural business, with AECO (Architecture, Engineering, Construction and Operation). Want to check? Visit Ingenious.BUILD on LinkedIn, we are hiring now. 

Ok, so what are the differences between them? Brownfield investment is an approach when we want to build something using existing terrains, existing buildings. We will have some existing problems to resolve, contaminations to remove or we will be removed by some law requirements related to the area we are interested in. Just imagine old buildings, maybe something like an abandoned former factory, big terrain you want to change to a new residential area. The Greenfield project is on the other hand something fresh. You have clean terrain and you can start everything from scratch, without checking anything from the past, no top-down restrictions, no complicated law processes.

The thing is similar in software development and software architecture, but with some important differences. According to what I wrote before, you can think that the greenfield project is always a better opportunity, and always gives us a better start. It is not true in the software world. Brownfield is like work with existing legacy code – and who does really like legacy, especially complicated legacy solutions? In this situation we have to rethink a lot of already existing parts of the system, we have to refactor some of them or just put them into the trash and write something again. It may be boring and it may be confusing for a lot of developers. The thing changes when we are at the point of contact between our code and our business requirements. Why?

The answer is simple: a brownfield project means we already have a lot of information. Yep, maybe we will need to adjust something, maybe remove or add something, but we already have a starting point, we already meet some business requirements and we can use that knowledge to improve our application. Just imagine building something like an Uber system from scratch and with something existing: there is a very very small chance that legacy code is completely useless: you can use it to determine requirements, check them and adjust. It’s even possible you will still use some of the parts, because they are good enough and will not require immediate refactoring. Also, if we already have some legacy solutions, we can easily add new members to our team, because we know what stack we use. It may not be super important at the start, but if we want to scale up, it will be more and more crucial for faster onboarding and verifying. Product part of our organization also has less to do, because we can reuse existing solutions. 

On the greenfield project the situation is only seemingly simpler. Of course we can start from scratch, but in most cases, we will have many more questions than answers: what are our real requirements? What business problems do we want to solve? What stack should we use for that? If everything is clear, we have all the information, then yep, it will be a piece of cake. But it’s a utopian assumption: we will not have all the information and business will verify our plans after first usage. That is why quick implementation – even if our application is not perfect, not ready for all cases – is so important: we will have feedback and it will be possible to make all required adjustments. And guess what… your greenfield project becomes a brownfield project then – you will avoid it only in very simple cases.