Contact

Do these 6 phases describe a project you’ve been involved with recently?

1. Enthusiasm

2. Disillusionment

3. Panic

4. Search for the guilty

5. Punishment of the innocent

6. Praise and honors for the non-participants

A cynical take on large-scale IT projects is often realistic. In fact, many projects we in software development call “brownfield projects” have been through these six phases, with nothing to show for it.

What Is a Brownfield Project?

A software brownfield project is one in which a development team that was not part of the original design or implementation is then asked to work on the software.

There are several reasons why this situation might arise, including:

  • A legacy system in which the original developers are no longer available but needs functional or performance enhancements, bug fixes, or migration to a new platform or technology stack.
  • A new software system is being implemented, and the legacy systems require some modifications in order to interoperate/integrate.
  • Regulatory or security requirements demand an update to legacy software to bring it into compliance.
  • The original team didn’t finish the initial implementation, either because of incompetence on their part, poor project management, changed corporate priorities, office politics, etc. In any case, the company wants to realize some value for the sunken costs and wants to finish the job with different developers.

“Greenfield projects” are started from scratch; brownfields are inherited. In some cases, a brownfield project can become a greenfield project if none of the original code can be salvaged.

Sometimes it costs less to start fresh than to try to fix the original code. In other cases, a greenfield project to replace a legacy system will refer to that system for business rules but won’t make use of any of the legacy code.

Brownfield Projects: Pros and Cons

Like any project, a brownfield project vs. a greenfield project has advantages and disadvantages:

Advantages to a brownfield project:

  • Finishing an incomplete project, or updating a legacy system, can be much more cost-effective than starting over again.
  • Much of the foundation has already been laid. Requirements have been gathered, some (or all) of the code has been written, and some testing may have been performed. Unless the original team went in a completely wrong direction with the system architecture or code, the existing code base can serve as a good starting point.
  • The hardware has usually already been purchased and set up by the time the new team starts work. Unless the wrong hardware was acquired, this part of the project doesn’t need to be duplicated.

Disadvantages to a brownfield project:

  • For any type of brownfield project, chances are good there are some nasty surprises lurking in the code or technology choices. Poorly written or inadequately documented code can be hard to interpret and may include bugs that are difficult to find and fix.
  • There will be a strong desire by the new developers to rewrite existing code, either for legitimate reasons (existing code is poorly organized or not optimized for performance) or personal/professional preference (the original code wasn’t written in the way the new developers would have done it). The new developers need to be careful to rewrite only the code that really needs it.
  • There’s often a fair amount of emotional baggage associated with bringing in a new team to finish an incomplete software project. The customer has already spent a lot of money on the project and has nothing to show for it, so there’s pressure on the new team to perform on a tight budget. It’s easier for the new team to become the scapegoat if things don’t go perfectly.

Each proposed brownfield project must be evaluated according to the pros, cons, risks, and expected return. The choice will often come down to cost: Will it cost more to start from scratch, writing off the expenses of the previous work? Is the existing system too much of a mess to try to salvage?

How AndPlus Evaluates Your Brownfield Project

AndPlus teams are happy to accept brownfield project work, whether rescuing a failed project or implementing some essential updates or enhancements to a legacy system. We approach these projects carefully and with eyes wide open before taking them on.

Here are the steps we take to evaluate a proposed brownfield project:

  1. Understand the history – We want to know the history of the project (especially if we’re being asked to take over an incomplete project) and the customer’s motivation for considering the brownfield approach. What was the problem with the previous developers? Are they no longer available, or did they fail to meet expectations in some way? What development methodology was used?
  2. Understand the state of the system – For incomplete projects, how far did the previous developers get, and what remains to be done? What technology and design choices were made, and why? Do these choices need to be revisited? For enhancements and updates, is the legacy system going to work for the foreseeable future, or is the proposed development simply keeping the system working long enough for a replacement system to go-live?
  3. Review the code in extreme detail – We perform a thorough audit of the code base to evaluate the quality of the code, understand how it works, find any obvious bugs, and identify what can be used and what needs to be rewritten. We do this both by manually eyeballing the code line-by-line and by use of automated tools such as SonarQube.

After we understand what you need, we can work on proposing a solution and estimating the time and cost.

Executing a Brownfield Project for Success

We then present the options to you. We sometimes propose a greenfield in addition to any brownfield options. We include the advantages and disadvantages of each approach. With this knowledge, you can make an informed decision: You can opt to proceed with the brownfield project or scrap it in favor of the greenfield process.

Once you decide which way to go, it’s time to formulate a detailed plan for executing the project. The brownfield project plan will normally be built around one of the following:

  • “Frankenstein” – If the existing software is already working (or mostly working) and it needs some new features and enhancements, we use what we call the “Frankenstein” approach. We design and implement new features that are bolted on to the existing code base.
    This approach can be useful when the life expectancy of the legacy software is short and some new features must be implemented to meet business needs until the launch of a replacement system.
    Another common “Frankenstein” case is where some part of the code just isn’t working and can’t easily be improved. We will toss out that part of the code and replace it with new code.
  • Greenfield option – If you choose to proceed with the greenfield process, the plan will be the same one we use for any new development project. The only difference is that instead of performing our normal requirements discovery process, we start with the requirements and business rules that were previously documented or existing software, and identify any new requirements or changes. (With the passage of time, the company’s priorities may have shifted. Some previously “must have” requirements are no longer needed.)
  • In-place improvements – If the system is expected to be in use for years to come, we will write the code that doesn’t exist and work to improve the existing code where applicable. We will optimize the code for performance, reliability, extendibility, and maintainability.

In all cases, we apply our tried-and-true Agile development methodology and involve you in every step of the process. We also perform thorough, end-to-end testing of the code we write as well as the existing code. This is especially important when finishing a project someone else started.

We show our customers that not all software projects are doomed to follow the six phases described earlier. With proper preparation, planning, and execution, software projects—even brownfield projects—can successfully deliver high-quality software, on time, and within budget, with no unpleasant surprises.

Finally, we understand that for whatever reason, we might not be the team working on the system “next time.” We thoroughly document our code and write easy-to-understand processes. That way, if other developers work on the software, they shouldn’t face confusion and uncertainty.

Brownfield projects can be risky. But if approached in the right way, they can be successful. At AndPlus, we welcome the challenge. If you have a brownfield system that needs attention, contact us today to find out how we can help.

Read On