It seems like someone by now would have figured out how to go about doing very large projects. The historic way of doing them is to break it into a few steps (analysis, design, implementation, and rollout), throw a heap of bodies at it, and try to manage the process. The weaknesses in this so-called waterfall model are well-known, but that doesn’t prevent it from being a popular alternative for many systems. This is particularly true in embedded systems, where conservative management practices have been reluctant to try any of the newfangled stuff coming out of the mainstream IT world.

That may be changing. A recent article on the Embedded Systems Programming site trumpeted the advantages of Extreme Programming (XP), which was quite the buzzword a year or two ago. The authors show the same unabashed enthusiasm as any True Converts to a new religion, but I’m not so sure their excitement is warranted.

Granted, there are some good ideas in XP. The concepts of iterative development and increased customer involvement can be very helpful. Unfortunately, many of the XP projects I have seen have used the techniques as an excuse for undisciplined development. XP done correctly is not free-for-all hacking. It requires detailed work to ensure that the iterations are converging rather than diverging. This discipline requires training and management oversight, which is too-often missing.

The sad thing is that when a project fails due to these factors XP usually catches the blame. There are good things and bad things about the techniques, but they can’t be fairly evaluated unless the techniques are actually followed.

Larry Mittag