I can’t count the number of times I’ve seen some nifty technology or development practice presented with the implicit assumption that everyone in the world is doing greenfield development. But in my entire career so far, both at commercial software companies and at internal IT shops, I’ve only ever been on one successful and one aborted greenfield development project. Everything else I’ve worked on involved taking something that already exists and adding some new functionality to it. Sometimes that’s one big sweeping change, and more often it’s a series of incremental changes.
The XP camp seems to acknowledge this reality the most, but even they make one critical assumption: the system you’re working on is fully covered by a comprehensive set of unit tests. In reality, if even one corner of your app isn’t covered by unit tests, then you can no longer refactor with abandon and not incur a high manual testing cost (or high production risk). If you can’t refactor with abandon, then you can’t design to today’s requirements and not worry about tomorrow’s requirements. If you can’t design to today’s requirements, then you can no longer start development without a waterfall-like comprehensive requirements process, and so on and so on.
For every presentation I see at a conference about a technology, I’d like to see a description of it in a greenfield environment and a not greenfield environment. Let’s call it a brownfield environment because our nice, open, green field (possibly with poppies and butterflies, etc) is marred by some gopher hole, or cow patties, or whatever our legacy environment presents us. Most metaphors are vaguely brown.
It should be possible to describe the average brownfield adoption of a technology or process, what the cost/benefit curve looks like at each step, and at what points people tend to lose courage. Maybe I’ll do it, between conference calls and diaper changes.