Richard Hopkins and Kevin Jenkins
IBM Press, 2008
ISBN 0137130120
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
I recently spoke at an RESG meeting, at which I showed a slide about brownfield and greenfield development. There was a big brown circle showing that a rhetorical 95% of projects were brown - building on existing products, systems, services and infrastructure. And then there popped up a big green square, asserting not altogether untruthfully that 95% of requirements textbooks, research and standards were for greenfield development. The audience chuckled knowingly.
The loudest laugh came from Richard Hopkins, who knows a thing or two about brownfield work. I held up a copy of my own Discovering Requirements textbook, and confessed that it gives just five pages explicitly to brownfield. Actually I was being a bit hard on myself - many of the techniques in the book, especially those paid little attention in other texts, are very suitable or indeed essential on brownfield projects. Stakeholder analysis, for example, becomes critical when stakeholder groups are numerous, powerful, and hold conflicting opinions, as becomes more and more likely as systems become older, larger, and more complicated.
Hopkins and Jenkins, both from IBM, are among the very first authors explicitly to address brownfield development, so their book is very welcome.
The book looks at what brownfield is, and what problems it typically has. It addresses key differences (at least for software) between pure, abstract theory and the messy, complicated reality of projects in an imperfect world. It looks, crucially, at life-cycles, and explains why neither pure agile nor pure waterfall will do. And it gives practical advice on what you have to do to go from a definitely difficult as-is state to an improved as-should-be state, on genuine elephant-sized projects. It concludes with advice to system architects on how to "eat elephants".
The problems are quite well known. Big projects often go wrong - not, probably, as often as the Chaos reports claim, but much too often nonetheless. Old code tends to become brittle: when it has been edited by many hands, sometimes badly hacked, sometimes with deliberate shortcuts on quality to save time - and been patchily documented, it gets harder and harder to change. Poor management, poor requirements work, globalization and sheer size all contribute.
The elephant-eating metaphor (see figure) is straightforward enough - big projects can't be eaten, ie delivered, using simple old-fashioned tools. Frozen elephants? It means simply that the giant project has got stuck. For instance, so many fixes have been made that changing anything is painful and risky - fix one bug and five more spring up.
The solution? Well, that's a bit more complicated. Attention to context and stakeholders is essential. The bigger picture - system architecture - is vital. And dialogue with the stakeholders is absolutely essential.
© Ian Alexander 2010
| USA, Worldwide: | From the UK: |
|---|---|