Agile methods

Another interesting article by Martin Fowler: The New Methodology (and again I’m several months late). The predecessor of this article in 2000 was equally interesting. In fact it still is. If you have the time, read both of them.

Martin Fowler, Kent Beck, Erich Gamma and other people of that generation have greatly influenced the way I think about software engineering. I’ve been a scholar in software engineering and currently my work at Nokia also involves a great deal of software engineering research. I see these guys as the pragmatic force driving the industry forward. While we scholars are babbling about Model Driven Architectures, Architecture Description Languages, our ivory towers, these guys are all “stuff and no fluff”. It’s a good thing to once in a while consider that many of the software engineering research community ideas and concepts in the past have done and continue to do a lot of damage. For example, the waterfall model (the mother of all software development methodology) is still being taught in universities. Out of touch SE teachers still teach their students to do things one after the other (instead of iteratively).

The original papers on the waterfall model, iterative development and related methodology from the seventies are an interesting read. Their authors had a lot more vision than past and present proponents of these methods. But they are just that: the vision of software developers coming out of the cold in the seventies. We’ve learned a lot since.

If there’s one thing you can learn from Martin Fowler, Kent Beck or Alistair Cockburn, it is that you should never ever implement their methodology to the letter. If you are doing so, you didn’t get it. Agile is all about change, including changing the way you work on permanent basis. The article I’m citing presently argues this in Martin Fowler’s usual clear fashion. Go read it already.

2 Replies to “Agile methods”

  1. my 2 cents: I think the future is definately in agile development. Most of the theory on SE / SA follows from large scale software project such as those at NASA or the american defense department. However I would argue 90% of all SE projects are small scale e.g. less then 25 engineers involved. I heard that only 7 engineers currently work on Microsoft excel. Most game projects are smaller than 25 people. I would not write off the waterfall model, it may work well in well-understood domains. The waterfall model does not work in game development as the “creative”/ explorative nature of games development often favors an iterative proces which allows for the required flexibility. Agile and waterfall are often at the opposing ends of the spectrum (ascii art copied from wikipedia)

    Adaptive Predictive

    In the best SE practices you should have a combination of both; certain high risk/uncertainty components favor an agile/iterative and other (well understood) can use the waterfall method. In game development this could for example be the 3D engine that is “iteratively/agile” developed and maybe some level loading modules that are well understood can be developed using a waterfall method. However its interesting to see what the “overal” method of your game development ends up in. If certain components rely on iterative/agile components your overall process is also iterative/agile.

  2. The problem in industry is that everybody starts out doing what they learned in college (the waterfall model). Then they figure out that doesn’t work for them and adopt one of the new shiny methods advertised on the bookshelf of most bookstores, currently that would be either something like RUP or Extreme programming. Most of these companies never evolve beyond the stage where they are just mindlessly doing what the book says. They don’t reflect, they don’t adapt. Arguably, methodology is the least of problems these companies have.

    They get away with it as long as the projects are small scale, short term (so 50% more work means two weeks delay). But as Microsoft is experiencing now, getting 100 Millions LOC out requires a different approach. Vista is late. Years late and they planned it to be years earlier. With all their billions they couldn’t do it. Large scale software projects with hundreds of man years and a time scale that covers half a decade are quite common now. It’s just that the vast majority of these projects don’t seem to follow a predefined plan.

Leave a Reply to Jilles Cancel reply