In today’s episode of our Meet the Author podcast series, Fritz Onion sits down with Donald Belcham to discuss his course Brownfield Application Development. In the interview Donald explains exactly what Brownfield development is as well as some of the strategies that can be used to help manage development in tightly constrained environments.
Listen to the Audio (MP3)
[Fritz] Hi this is Fritz Onion. Today I’m here with Donald Belcham to talk about his course Brownfield Application Development. Donald is a senior software developer, independent contractor, and agile development expert who is a strong supporter of fundamental OO patterns and practices. He’s also the co-author of the book Brownfield Application Development in .Net published by Manning Press in 2009. Donald, thanks for taking the time to talk with us today.
[Donald] Not a problem.
[Fritz] So this course of yours, Brownfield Development, I think we may have some developers out there that perhaps aren’t familiar with that term Brownfield. So I thought it’d be good to start with what exactly does that mean? What is the Brownfield project and what does it mean to do Brownfield application development?
[Donald] Yeah, most of us are used to the term Greenfield, it’s file new project type of stuff that we’re doing in our workplace. And Brownfield is the flipside of that. It’s the stuff that we’re going into on projects where there’s existing code bases already. And we have to work with that, we have to continue to be able to deliver to our clients, whether that’s new features or bug fixes and things like that. So we’re working in a different style of project with a different set of constraints around us. If you really want to go to the extreme you can even say that your average Greenfield project is actually a Brownfield project after the 1st line of code is written, because you’ve decided on something where there’s a constraint now in your code base, and you have to either work with it, work around it, or change it as you move forward.
[Fritz] That makes sense. Just from my own experience I think it must be upwards of 80, 90 percent of most projects are in this category. Don’t you think?
[Donald] Absolutely. I have, in my career, worked on maybe 3 to 4 projects that are actually pure file new project where Greenfield and that’s how we start out. Most of the time you’re inheriting a code base, or you’re inheriting some kind of architectural or technical constraint right off the start.
[Fritz] OK, so Brownfield is working on a project that already has some code in it essentially. So what are the problems that you try to address in this core? What are we going to run into?
[Donald] There’s a number of different things that you’re going to see when you’re working in Brownfield stuff, and probably the first thing you notice is you join a project or the project gets handed to you, and there’s a lot of either political or social overhead involved in it. It’s probably not be overly successful, or they’re having problems that are going to appear to the client to give it the perception of a lack of success in the future. So lots of times it’s things like lots of defects, poor ability to deploy the product, or an inability to deploy the product in a working manner. And it’s those types of things that are the first thing to jump out at you. So you’ve got to learn how to deal with them, or figure out how to deal with them. And it could be anything from automation of build scripts and release process, to including automated testing, or some kind of testing on projects that don’t have any testing at all; and try and address those points before we even worry about any of the other problems that exist in the code base, or on the project overall.
[Fritz] Then I should mention this is kind of the path that your course takes. You introduce people to the concept of the Brownfield project, and then you talk about how you can enhance your environment so its easier to actually make changes to the code base and add features to it. So you get into the test and safety nets, isolation, identifying pain points, and creating layers. So I can very easily see how sort of adding, or building up some infrastructure around the project is really essential to give you confidence in adding new features. What about the code side of it? What sort of things do you run into as you’re actually writing code and integrating with the existing code base that you can sort of generalize in this types of things?
[Donald] Probably the biggest thing that I’ve seen when I’ve looked at code bases is that we have this problem where you go in to change the code, and the cascading effect of that change is either not known or unseen for a long period of time, to the point where the cascading effect may not be seen until it goes to production, and then you get a bug report based on, hey we’ve done X-Y-Z in here, it used to work, now it doesn’t. And usually that’s all caused by one of two things, or a combination of both I guess as well. It’s tight coupling and code that is way too large for its own good. So I’m thinking here the single responsibility principle. So we’ve all seen the code behind pages on web pages or WinForms where there’s 20,000 lines of code behind one screen. It’s not possible for us to have any confidence that changing a small part of that is not going to affect any other part of it, so this is one of those types of things that we’re going to see right off the start is huge amounts of code where there shouldn’t be huge amounts of code, and that code is probably tightly coupled to other places. So changing it in one spot has negative side effects in another location as well. And in a Brownfield project we want to try to figure out how to stop this from happening. How do we take our code and decouple it? How do we whittle it down so it’s more manageable and ultimately more testable as well? And this is probably one of the first steps that we have to take on every single Brownfield project.
[Fritz] And what are some of the… I mean, I can imagine people would get to a point where they’re potentially considering rewriting the whole thing after trying to loosen the coupling. Do you have any advice on how to approach that dependency reduction, or techniques you can use?
[Donald] Absolutely. It’s probably the first response that I always have on a Brownfield project, is oh dear God we need to rewrite this whole thing. While that may be true it’s not something you can pitch to the client very easily at all. So you know what, we’re going to stop doing everything, you’re getting no features, no bug fixes, none of that kind of stuff because we screwed up and now we have to fix it, and you’re going to pay the price for it. So instead we have to figure out a way that we can incrementally change these things while being able to parallel feature and bug development efforts, so we’re not giving that negative impact to the client. And there’s a couple of things we can do there, one of them going back to infrastructure type stuff is, ensuring that we have a source control system that allows us to work in isolation. This is a huge part of the whole thing, is being able to work in isolation. And at the root level source control helps us there. Can we create branches? Can we do merges easily to bring those changes back in? Can we have multiple branches open at one time? All of that kind of stuff. And once we’ve got that foundation and that infrastructure to enable us to work in isolation, now we can start looking at the code and working on very, very small pieces. My initial tact is always to try and take one piece of functionality from one small screen, and get that refactored from the top all the way to the bottom. So all the way from the UI down to the database. And so it might just be the loading of the data into the screen, refactor the whole thing, get it into the layers that you want, get it structured so that it is testable, so it’s not tightly coupled, all those types of things. And then after you’ve got that one thin vertical slice you can take off another slice next to it. And eventually after doing a whole bunch of these slices you’re going to have some structured code that is showing the layers you want in your architecture, as well as the testability coming through on it, and those types of things. And you’re probably going to end up finishing off one whole screen. And then all you do is move on to another piece, another screen probably, and do the exact same thing over and over. So as you’re doing these thin slice refactorings you can stop at any point in them. You can refactor all the code out of the code behind, and then stop and say you know what, I’m willing at this point in time to accept that we have this huge blob of code that’s not in the code behind, and I’ll refactor it a little bit more next week; but right now I’ve got to go and do defects. So you can do that kind of thing if you take the thin vertical slices, and then fraction them off into a UI refactoring, and maybe a service layer refactoring, and maybe a data access layer refactoring, and you do each one independently; and now we’ve got this ability to both work in isolation and to release the new code base, as well as release features and defects.
[Fritz] Right, so doing it incrementally has a lot of benefits so that you can continue your new feature path as well.
[Donald] Absolutely, but you can’t do it without… you’re not going to, most projects in my experience you’re probably not going to be able to take a development team and say you know what, these 3 guys from the development team are going to be just refactoring the code base and everybody else is going to work on new features. You’re probably going to have people that have to do both things at different times during the day, and or week, or month, or whatever your release cycle is to.
[Fritz] Right. Great, so this is Donald Belcham with his course Brownfield Application Development. Definitely worth checking out if you are on a project where you have to work with existing code bases. Thanks very much Donald.
[Donald] Thank you.