About the book

This is a sample chapter of the book Brownfield Application Development in .NET. It has been published with the exclusive permission of Manning.

Written by: Kyle Baley and Donald Belcham
Pages: 416
Publisher: Manning
ISBN: 1933988711

Introduction

An industrial brownfield is a commercial site contaminated by hazardous waste that has the potential to be reused once it's cleaned up. To a software developer, a brownfield application is an existing project, or codebase, that may be contaminated by poor practices, structure, and design, but that has the potential to be revived through comprehensive and directed refactoring.

Many of the established applications you'll encounter fit this description. By the time you start working on them, the core technology and architectural decisions have already been made, but architectures and technologies are still more easily repaired than replaced. In this article, we'll explore the various components of a brownfield application.

The components of a brownfield application are:

• Existing codebase
• Contamination by poor practices
• Potential for reuse or improvement

Figure 1 shows the three components, which are interrelated.

Figure 1: Brownfield applications have three components that distinguish them from greenfield and legacy applications.

It's easy to distinguish a brownfield application from a greenfield application. Greenfield applications have no previous project or technical history, whereas brownfield applications are typically burdened with it. Similarly, we make a distinction between brownfield and legacy applications as well. We'll come back to legacy codebases shortly, but for now consider them to be applications that are long forgotten and that are worked on only when absolutely necessary.

Brownfield applications generally fall between greenfield and legacy. Table 1 compares the three types of projects.

Table 1: A comparison of major project concerns and how they relate to greenfield, brownfield, and legacy applications

In short, brownfield applications fall into that gray area between when an application is shiny and new and when it's strictly in maintenance mode. Now that we've provided the criteria for a brownfield application, let's examine the components from figure 1 in more detail.

Existing codebase

One of the defining characteristics of a greenfield application is that there's little or no prior work. There's no previous architecture or structure to deal with. By contrast, brownfield projects are ones that have a significant codebase already in place.

We don't mean that when you leave work after the first day, your greenfield application magically turns into a brownfield one overnight. Typically, it has been in development for some period of time (or has been left unattended) and now has some concrete and measurable work that needs to be done on it. Often, this work takes the form of a phase of a project or even a full-fledged project.

There are a couple of points worth mentioning with respect to existing codebases, even if they're a little obvious:

• You must have access to the code.
• The code should be in active development.

These two points disqualify certain types of applications from being brownfield ones - for example, an application that requires occasional maintenance to fix bugs or add the odd feature. Perhaps the company doesn't make enough money on it to warrant more than a few developer hours a week, or maybe it's not a critical application for your organization. This application isn't being actively developed. It's being maintained and falls more into the category of a legacy application.

Instead, a brownfield codebase is an active one. It has a team assigned to it and a substantial budget behind it. New features are considered and bugs tracked.

The next component of a brownfield application is the degree to which it's contaminated. Let's see why this is an important aspect of the definition.

Contaminated by poor programming practices

Besides being an existing, actively developed codebase, brownfield applications are defined by their level of contamination, or smell - that is, how bad the code is. This determination is subjective in the best of cases but, in many instances, everyone agrees that something is wrong, even if the team can't quite put their finger on it or agree on how to fix it.

Different levels of contamination exist in any codebase. It's a rare application indeed that's completely free of bad code and/or infrastructure. Even if you follow good coding practices and have comprehensive testing and continuous integration, chances are you've accrued technical debt to some degree.

Along the same lines, contamination means different things to different people. You'll need to fight the urge to call code contaminated simply because it doesn't match your coding style.

The point is that you need to evaluate the degree to which the code is contaminated. If it already follows good coding practices and has a relatively comprehensive set of tests but you don't like the way it's accessing the database, you could argue that it isn't a full-fledged brownfield application - merely one that needs a new data access strategy.

Although it may be hard to pinpoint the exact degree of contamination, you can watch for warning signs that might give you a gut feeling:

• How quickly are you able to fix bugs?
• How confident do you feel when bugs are fixed?
• How easy is it to extend the application and add new features?
• How easy would it be to change how you log error messages in the application?

If your answer to any or all of these questions is a chagrined "Not very," chances are you have a lot of contamination.

Bear in mind that every application can be improved upon. Often, all it takes is a new perspective. And like any homeowner will tell you, you're never truly finished renovating until you leave (or the money runs out).

So far we've discussed the nature of the application and talked about its negative aspects. With the final core component of a brownfield application, we'll look at the positive side of things and see what can be done to make our app better.

Potential for reuse or improvement

The final criterion, potential for reuse or improvement, is important. It means that despite the problems you've identified, you're confident that the application can be improved. Your application isn't only salvageable but you'll be making an active effort to improve it. Often, it's an application that you're still actively developing (perhaps even still working toward version 1). Other times, it's one that has been put on hold for some time and that you're resurrecting.

Compare this with a traditional legacy application. Projects that have aged significantly or have been moved into maintenance mode fall into the legacy category. Such applications aren't so much maintained as they are dealt with. These applications are left alone and resurrected only when a critical bug needs to be fixed. No attempts are made to improve the code's design or to refactor existing functionality.

As you can see, it isn't hard to come up with an example of a brownfield application. Any time you work on an application greater than version 1.0, you're two-thirds of the way to the core definition of a brownfield application. Often, even applications working toward version 1.0 fall into this category.

Summary

In this article, we defined brownfield applications and showed how they compare with greenfield and legacy applications. We also discussed the three components of brownfield applications - existing codebase, contamination by poor practices, and potential for reuse or improvement - and how they interrelate.

About Manning Publications

Manning Publication publishes computer books for professionals--programmers, system administrators, designers, architects, managers and others. Our focus is on computing titles at professional levels. We care about the quality of our books. We work with our authors to coax out of them the best writi... This author has published 33 articles on DotNetSlackers. View other articles or the complete profile here.