The Greenfield to Brownfield Transition

There’s a special moment in every project where it transitions from a Greenfield (new) project to a Brownfield (legacy) project. This moment usually occurs close to the second release.

As developers, we love Greenfield projects. It’s a new adventure where creativity runs wild and free.

The transition of a project from Greenfield to a Brownfield is an event that we can all appreciate. It’s delicate and requires attention from everyone on the team.

During this transition the architecture starts to settle, patterns and practices start to immerge. New features now require developers to examine what can be reused. Quality Assurance personnel has expectations and can put more effort on exploratory testing. Team members are often called to contribute to new projects and knowledge transfer becomes crucial.

On Microsoft Azure (a.k.a Azure), this transition comes rather quickly. Azure is a platform that evolves at a very fast pace. Each release is accompanied with new features and services that create new opportunities. These opportunities drive teams to reassess their strategy in order to gain an edge on competitors.

Regular reassessment of a team’s strategy is crucial in modern development practices. The Application Lifecycle is often composed of an analysis phase, a build phase, a release phase and an observation phase.

On regular occasions, we forget about the observation phase. This is where Brownfield projects go bad, because this forgotten phase is an invaluable source of feedback. Feedback that must be used to drive subsequent efforts.

Types of Feedback

• Application Metrics – metrics are great at providing insight and context about a live application. They can be used to troubleshoot, monitor and identify areas that require more effort.
• Consumer Feedback – applications often use services like UserVoice to empower consumers to provide feedback about their experiences and suggestions about missing features. Remember, consumers use your application because it satisfies their needs. Missing features, quality issues and lack of support will drive them away.
• Development Metrics – development metrics including but not limited to test coverage, number of lines of code, number of defects, average number story points covered per sprint, cyclomatic complexity and number of defects versus number of new features are crucial key performance indicators (KPI) that help teams refine their practices.

The success of a project depends on a successful transition from a Greenfield project to a mature Brownfield project. This transition must be prepared adequately. Failure to do so usually results in developers demanding rewrites. Those who find themselves in this delicate situation are rarely happy. They lose interest, passion and fear the code base. Our industry has named this Fear Driven Development (FDD).

Preparing for the transition starts on day one. A solid organic architecture that follows best practices is the foundation for everything else. Architectures are hard to change. Therefore, it requires constant attention from everyone on the team. Developers, Architects, Team Leads, Testers and Management must be critical and raise issues as they come up.

YAGTNI (you aren’t going to need it) is a principle that helps to manage technical debt. Its premise lies in the practice of building only what you need for the current release. Building for future releases often results in rigidity that we must deal with for the project’s lifetime.

Rigidity robs us of future opportunities. I see this regularly, when project efforts are geared towards a database centric design. The database becomes the business domain and the application itself. A change to the database results in lots of effort because the entire application is affected. Good architectures strive to protect against this sort of rigidity by creating opportunities to use different storage strategies for different workloads.

Azure is all about opportunities. Using design principles like Dependency Inversion, teams build flexible designs that can evolve and adapt to an ever changing ecosystem.

Preserving a project’s agility is an ongoing process that starts on day one. Take time to address technical debt early. Iterate, assess and course correct on a regular basis. If your development process hinders you from producing quality software, try something different. Adapt your process as your team and project mature.

So the next time you’re invited to participate on a Brownfield, don’t panic. Iterate, assess and course correct. If you get invited to participate on a Greenfield project, tell yourself that it’s your chance to experience the transition. Your efforts and your open mind will make the difference.