Stupid Question 176-179: Is Greenfield field good and Brownfield bad, what is that, and what is legacy code?
“Few of you will work on a greenfield project, maybe one or two the first few years. Make sure that you are prepared for brownfield work.”
In the very beginning when I started learning programming at school we started of learning programming without generics and dynamic, which got us all very curious. As we started learning that – eager to know what is to come- we asked our teacher why didn’t start of straight away with the good bits. The quote above is what he replied, and what he meant was that it was important to be able to work on legacy projects, and to be aware of restrictions and possibilities.
I must have been the odd one out, because since I started programming I’ve only been on two brownfield projects, and quite a few greenfield ones- and I’ve enjoyed the luxury knowing that it might change at any moment. And that is how I came to think of this question, is greenfield good and brownfield bad?
Let’s start of by explaining the two terms, greenfield is often a new project, untouched and therefore with restrictions (aside from those from the customer etc.).
Wikipedia:
In many disciplines a greenfield is a project that lacks any constraints imposed by prior work. The analogy is to that of construction on greenfield land where there is no need to remodel or demolish an existing structure.
Brownfield is a project that already exists and you have to work with the existing code be that change it, maintain it or whatever.
Wikipedia:
Brownfield development is a term commonly used in the IT industry to describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing (legacy) software applications/systems.
When you read the Brownfield Land definition in Wikipedia the way Brownfield is explained is often how I fell it is viewed even in software:
Brownfield sites are abandoned or underused industrial and commercial facilities available for re-use. Expansion or redevelopment of such a facility may be complicated by real or perceived environmental contaminations.[1]
It’s something negative. But is it? Notice how I didn’t use the word legacy code. This is where I might be wrong, but for me legacy code is unsupported code- and code that will very likely cause grief and problems.
I’ve seen legacy code in a Brownfield project, and I’ve seen Brownfield projects that are far from legacy. But nonetheless Greenfield seems to symbolize the ultimate freedom, it’s pure and untouched and you get to play creator and work on those ‘the-perfect-project-dreams’ (which as I’ve understood rarely work out). The irony is that as soon as you write those first few lines of code it isn’t green anymore, and wait long enough without change and it even becomes legacy.
I doubt I gave an answer here, I probably just offered an opinion, and my opinion is that to be correct- Brownfield merely states the state of the project and not the quality or whether or not it’s legacy, and therefore while Greenfield gives you more freedom, it isn’t about good and bad projects, but just different project states- both with pros and cons.
***Curious to hear what you think :)***
Comments
I believe greenfield projects remain greenfield until your code is constrained by factors outside the development team. Integration by shared database (shudder), user data beyond your reach or some such. Until you have that, at least before your first release, your field is still green. While you can still refactor freely and change interfaces and break binary compatibility in assemblies et cetera, when all you need to do is to make sure that your fellow developers on the team are all aware what big changes are being made, your field is still green. Thus, greenfield can be a state that you can maintain surprisingly long if you work towards that goal, or you can shoot yourself in the foot and lock yourself out of any ability to change interfaces almost immediately.
For me, Legacy code refers to systems which are in place, have been for a long time and work so well that it is pointless to rewrite them, or which, due to their age "no-one really remembers how they work, but they do, so just incorporate them into the new systems". An example is the prevalence of COBOL code in financial institutions - it is estimated that 85% of all banking transactions are procedd in part by legacy cobol systems. And there are fewer and fewer people out there who can still read/understand COBOL code...
There was a time (somewhere this century) where Microsoft called everything which was not their latest products or technology, legacy. Btw: "Required fields are marked '*'": none required? (and in IE9 Name and Email fields are unreadable).
I think it is best for one's development to alternate between the two. Working only in green field runs the risk of isolating you from the consequences of bad decisions made. At least those that don't surface immediately. So there's a chance that one keep making the same bad decision in the following projects. So either work a on an existing brown field or just stay long enough in the same place for one of your green field projects to turn brown. ;) Brown field that one haven't been involved in from the start are also a good place to see what solutions other people made to problems. But, at least for me, green field is of course the dream for a developer. Working only on brown field, especially where you weren't involved from the start could be just fixing other peoples messes. I can only do that for so long before I start longing for the opportunity to create my own bugs. :)
Brownfield does indeed sound rather negative. However, I think this is really a sliding scale and that most projects are not strictly green- or brownfield. As soon as major architectural decisions have been made and no longer changeable without considerable effort, I don't consider something to be strictly greenfield anymore. Perhaps that's just me however :) I'm a bit puzzled with your teacher's reasoning, I must say. Sure, it's good to realize that generics weren't always around, there is plenty of legacy in the .NET framework to remind us of that. Actively avoiding these new language concepts to prepare you for legacy code is not something I would have done though. It reminds me of how physics was taught to me in high school. Teaching one abstraction which failed to explain reality in many ways, then the next year replacing it with a slightly more accurate abstraction, and so on. Of course, there's only so much information a person can take in at once. But I would have appreciated the teacher being upfront about these things. Making people aware that there is more, but explain them that this is what you'll work with for the time being. The same applies to many programming subjects. If you're still learning base concepts like variables and object oriented programming, it's not necessary to explain generics in-depth, but you could make people aware that there is such a thing. On the other hand, "dynamic" is a good example where I agree the subject should be avoided until the student has gained enough experience to realize the cons of using it.
Last modified on 2013-04-15