Ask Your Dev Team if they take on brownfield projects
Not every developer will work on existing code. Learn what brownfield means, why it matters, and how developers evaluate whether to take on your project.
Let’s cover what “brownfield” means.
In software development, the term brownfield describes an existing software application or system that has already been developed. The term comes from land development, and it implies the existing application has a history and has undergone previous changes, updates, and customizations.
The other side of this is called greenfield, a new software application or system built from scratch, without any existing code or infrastructure in place.
Why greenfield is easier
Greenfield projects offer several benefits over brownfield ones:
- Developers have complete control over the software’s design and architecture
- They can use the latest technology and best practices
- This leads to a more efficient, scalable, and maintainable system
- Fewer technical debt and legacy code issues
- A more flexible and agile development process
In general terms, a developer isn’t inheriting a host of decisions and stylistic choices from someone else. They’re free to employ their own, which makes them more efficient.
When would a developer take on brownfield?
With the increase of digital transformation, the impressive volume of mobile applications, and more people getting into tech, the truth is there are more brownfield projects out there. To be one, it implies some staying power in the market, an indicator that the company has established product-market fit.
There are many reasons a development project can change hands, but the most common case is when you’re hiring a new developer because you’re no longer working with the old team. That could be due to poor performance, which itself implies either poor communication, slow deliveries, or low work quality.
For most developers, this could be a warning.
How developers evaluate brownfield projects
When evaluating a brownfield project, a developer has to consider if their team can deliver better than what you’ve experienced before. They probably have criteria for evaluating brownfield projects:
1. Is the project distressed beyond recovery?
This can be missed deadlines, depleted budgets, or other constraints that make it difficult to meet quality standards. Some might call this a “rescue,” and it’s not a good foot to start on.
2. Is the code base up to standards?
When you adopt best practices, it makes it easier to maintain a project well into the future. Here are the key things developers look for:
- Does the project contain tests? How was quality assurance maintained?
- Was the project managed using source control? Did the previous developer use Git and store the code on a reputable repository host?
- Are there aging libraries or frameworks? Even popular languages have expiration schedules, meaning they no longer receive updates or patches. This can be a huge risk to your application’s security.
And this is just a sample of the criteria most developers use.
I hope this issue has taught you a little about legacy software development. The answer to “will you take on our brownfield project?” isn’t black or white. Now go out there and build something, and expect better from your developer.