Some years ago, Harlan Mills proposed that any software system should be grown by incremental development. That is, the system first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below. . . . Nothing in the past decade has so radically changed my own practice, and its effectiveness. . . . One always has, at every stage, in the process, a working system. I find that teams can grow much more complex entities in four months than they can build. — Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering” Read more →
EppsNet Archive: Fred Brooks
Respect the Classics, Man: No Silver Bullet
This essay by Turing Award-winner Fred Brooks is almost 20 years old now. Sadly, the ideas on incremental development are still considered outside the mainstream in IT, which continues to favor the widely-discredited waterfall approach. Read more →
The Waterfall Approach Persists as an Urban Myth
Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. — Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering” We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural . . . All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something… Read more →
Two Simple Rules
More software projects have gone awry for lack of calendar time than for all other causes combined. — Fred Brooks, The Mythical Man-Month As a corollary to this, I’d say that lack of calendar time very often forces us to admit that our projects have gone awry. Denial is a viable strategy when delivery dates are far in the future, but when the deadline is staring you right in the teeth, the time for sunny optimism is over and the time for the Day of Reckoning (DoR) meeting is at hand. I attended one such DoR meeting yesterday afternoon . . . This particular meeting broke down into a battle between the Designers and the Implementers. The Designers — who happen to be the more senior members of the team — felt that they had written the specs in such excruciating detail that the system should pretty much have coded… Read more →