Brownfield Application Development

How to work with Brownfield codebases
Course info
Rating
(130)
Level
Intermediate
Updated
Feb 16, 2012
Duration
2h 48m
Table of contents
Description
Course info
Rating
(130)
Level
Intermediate
Updated
Feb 16, 2012
Duration
2h 48m
Description

Every codebase becomes a Brownfield codebase sooner or later. You can even take the stance that every project is Brownfield after the first line of code is written. As a result it's important for us to understand how to work effectively and efficiently in these codebases. This course outlines environmental and technical tools that you can use to make working with Brownfield codebases more manageable.

About the author
About the author

Donald Belcham is a senior software developer, independent contractor, and agile development expert who is a strong supporter of fundamental OO patterns and practices. Since 2007, he has been awarded the Microsoft MVP Award in C# and is a member of the JetBrains Academy.

More from the author
What’s New in PostSharp v3
Intermediate
51m
Jan 30, 2014
Microsoft Fakes Fundamentals
Intermediate
1h 56m
Oct 10, 2012
FakeItEasy
Intermediate
1h 21m
Aug 20, 2012
More courses by Donald Belcham
Section Introduction Transcripts
Section Introduction Transcripts

Introduction
Hi my name is Donald Belcham and I'm going to guide you through this course on Brownfield Application Development. Throughout this course on Brownfield Application Development we're going to look at a number of different tools and techniques that will enable you to improve the codebase that you're dealing with. Probably the largest overriding factor we need to be concerned with is the idea that we still need to be able to deliver defect fixes and new features while improving the codebases at the same time. We want to be able to do those improvements in a controlled fashion using techniques and tools that will allow us to have easier development when we go to make future changes to our codebase. One of the things we need to look at first is what are the constraints that a Brownfield project will impose on you as a developer.

Development Environment
Donald Belcham: Hi. My name is Donald Belcham, and in this module of the Brownfield application development course, we're going to be looking at working in Brownfield development environments. Being effective in a Brownfield development environment is very different from other environments. The challenges that we'll face will range from having source code in the version control system that does not compile when you retrieve it all the way through to a project that has no confidence in the ability of the team to deliver in a timely and quality fashion. One of the biggest things that we need to do to be able to be effective is manage how the changes are being made within our development environment. There's a number of ways that we can do that, and we'll look at those in this module. The one thing to remember is that we should be able to deliver our code base to production in spite of the changes that we're trying to make. Delivering functionality, whether that be defect fixes or new features, it, within a Brownfield code base is not at odds with improving the code base at the same time. This is something key that we need to work on and remember so that we can be effective in our development environment.

Identifying Pain Points
Donald Belcham: Hi. My name is Donald Belcham, and in this module of the Brownfield application development course, we're going to look at how to identify pain points on your project. This module will help to define what a pain point is, and we'll also look at how you can search for pain points using a defect tracking system through social interaction and looking at the code base of the project you're working on. All developers know what pain points on. We work with them and work around them on every project that we're on. A pain point is something that slows down our development effort, whether that's coding of the process of development. These are things that restrict us from being able to achieve our end goals They are also points of frustration on the project. So these are things that whether it be an end user, a tester, or a developer that causes some kind of angst in that person about the overall project. It could be the way that the UI works, or it could be the way that the process of delivering the software works as well. These people have also become trained to think about work arounds. Might be that there is a process or a method in place in the user interface that allows the user to accomplish their end goal, but it is full of friction and work arounds. Could also be that the developers are working on something, and there are extra steps they have to take to work around some problem that is there in the process. One thing we have to be very careful about is that we don't become numb to these work arounds or to these friction and pain points. It's very common for us to not even know that we're numb to them. So we have to keep a vigilant eye to notice them.

Isolation
Hi, my name is Donald Belcham and in this module of the Brownfield Application Development course we're going to look at how working in isolation can benefit your project. There are a number of reasons that we would like to work in isolation on Brownfield projects. This module's going to show us how branching, identifying code boundaries, and creating seams can be used to create isolation and benefit our project. ( Pause )

Tests as Safety Nets
Hi. My name is Donald Belcham and in this module of the Brownfield Application Development Course, we're going to be talking about how to use tests as safety nets. There are a number of reasons that we want to have automate tests in our code base. One of the overriding reasons is that we want to have increased confidence in our code base and know that it's doing what it's supposed to be doing. When we're working in a Brownfield environment, there are a couple of things that we have to think about as far as automated testing. The first one is how do we go about reintegrating any test that may already exist in the project, how do we make them so that they run correctly and give us that increased confidence. Another thing that we need to think about is how do we go about adding new test to the code base, this may be new test for old code, or it may be new test for new code. These are some of the things that we're going to cover in this module.

Creating Layers
Hi My name is Donald Belcham, and in this module of the Brownfield Application Development course. We're going to look at creating layers in your codebase. Some of the things that we're going to cover in this module include a definition of what layers are. We're also going to look at how you can take that definition and create layers within your codebase using different techniques. We're also going to get a better understanding of what scenes and why they're important within our codebase. Finally, we're going to look at the complexity of refracting user interfaces to different patterns.

Risk and Corruption
Donald Belcham: Hi. My name is Donald Belcham, and in this module of the Brownfield application development course, we're going to talk about risk and corruption in the code base. When we're talking about risk and corruption, what we're really getting at is how do we handle the dependencies in our code base that we can't control, and it's these dependencies that are going to introduce a potential risk of failure to our project if we can't figure out how we can manage the life cycle and the changes that they're going to implement as we continue within our own code base.

Releasing
Hi, My name is Donald Belcham, and in this module of the Brownfield Application Development course we're going to talk about releasing your brownfield projects. In my experience brownfield projects suffer a lot under the problem of release management. One of the biggest problems they have is actually making a release happen. One of the reasons for that is that they've got a manual process instead of an automated one. Another thing that the project suffers from is a poor release quality experience. This might mean that they have poor install experience as due to poor management of configuration, or missing files, or a low quality package overall. In this module we're going to talk about those things and see what we can do in a brownfield project to improve them. ( Silence )

Overriding Principles
Donald Belcham: Hi, my name is Donald Belcham, and in this module of the Brownfield Application Development course we're going to look at some of the overriding principles that you'll need to be concerned with on your Brownfield projects. One of the first things that we need to think about when we're working on a Brownfield project is how do we manage the expectations of developers, project managers, and the end client. We also need to look at how we deal with the motivation of those groups of people as well. How do we keep them engaged in the efforts that are required to improve the Brownfield project. We also need to think about how we're going to reflect on the progress that we're making on the Brownfield project, at times it may not seem like we're making much progress. But none the less, we need to think back and see what have we done and how far have we come. We also need to deal with developer practice regression or reversion. It's the fact that developers will slowly try to slip back into old habits, which may be bad habits, and the code base starts to slide away from the direction that we're trying to take it as we improve it.