On designing software: DUD, RERO and BLOAT

My previous post, Ernestine Gilbreth Carey, 98, Author of Childhood Memoir, noted the death of Ernestine Carey. She was the daughter of Frank Bunker Gilbreth.

Frank Bunker Gilbreth was a seminal figure in the areas of motion study and industrial efficiency, and a man who had a major impact on the way things were built. He spent decades studying the ways people move to develop techniques that would let them become more efficient in their movements. His work was related to that of Frederick Winslow Taylor. Taylor’s tool was the stopwatch. He would break a task into its components, time each task, and then seek ways to perform the subtasks more efficiently and more speedily. The best expression of this approach can be found in Charles Chaplin’s movie “Modern Times,” of which the cited Wikipedia article says:

“Modern Times” (1936) depicts the dismal situation of workers and the poor in industrial society. The Eating Machine scene depicts the dehumanizing effect of mechanization.

There is another famous scene showing Chaplin with a six-foot wrench trapped in some large machine.

Gilbreth and Taylor were among the founders of the notion of “scientific management,” the belief that scientific and engineering techniques can be used to improve management and manufacturing processes.

Some of these techniques have been applied to software design. Indeed, there is a whole discipline called “software engineering.”

While Software Engineering is a worthy discipline in its right and can provide useful insight, unabated belief that the way to progress is to improve the process is often unwarranted.

I was reminded of this in a discussion about 15 years ago, in the early 90’s, while Fran Allen and I were driving to an airport. Fran is one of those rare people about whom it is impossible — absolutely impossible — to say anything bad. She was my first — and best — manager at IBM. She was the first woman to achieve IBM’s highest technical honor, IBM Fellow. She is also a friend of close to forty years, though I haven’t seen much of her since her retirement a few years back.

We were discussing the problems IBM had developing software. She said her view was that much of the problems resulted from a belief that came out of the 360 days, perhaps first inspired by the work of Fred Brooks. the chief designer of the software for IBM’s System/360 and also the author of the wonderful book, The Mythical Man-Month: Essays on Software Engineering .

Fran’s thesis was that the root cause of IBM’s problems was the belief that to write software was to manufacture it, that writiing software could be managed using the same techniques and methods that worked so well in building large mainframes. She felt that IBM was spending far too much time — and wasted time to boot — in the belief that each small increment in the process will result in an improvement in the software produced using the process.

The great fallacy in this, as every programmer can attest, is that the best programmers are much better than the average programmer. For example, I happened to be in my gym this past Sunday morning during the running of the NYC Marathon. I pushed myself a bit and managed to average just under 6 mph over a half-hour span, about 10 minutes/mile. The world’s best marathoners run about 5 minutes/mile. That is amazing but their velocity was only twice mine. But the best programmers are tens or hundreds of times better than the average programmer, and the best can do things that no average programmer can ever do. They can write code of such quality and at such a pace they have only a handful of peers in the world.

The belief that the secret of software development is in the design of the process is an example of a software development process discussed earler in these posts: Design Until it Drops (DUD).

I also wrote in the same post about another model, the model used in the open-source community: Release Early, Release Often (RERO).

But as it happens that post was about golf; see Woods Adjusting to His New Role: Helping Rookies, in which I made an analogy to software design approaches and learning how to swing a golf club.
Ken Coar later mentioned another model via a comment.

Here are the three software-development models so far mentioned:

DUD: Design it Until it Drops

The approach that the design must be perfected before coding can be begun, or that the design must evolve in tandem as the code is developed, with no release until the software has been perfected, though in practice this approach often results in no software, as designers and developers drop by exhaustoin.

RERO: Release Early, Release Often

The approach that softwar should be released early, so all in the community can see it and then work to fix and improve it, initiating a cycle of successive releases, as often as possible.

BLOAT: Bug Limitation through Optimised Audience Targeting

The Software Development Model BLOAT: Bug Limitation through Optimised Audience Targeting

Ken relates this is based on John Brunner’s “first type of fool1.”

The BLOAT model relies more on social engineering than actual code; while existing bugs may or may not be corrected, attention is drawn away from them with the equivalent of, “Look! Something shiny!” End-user reviews used for marketing purposes are collected from those who like the shininess rather than those who have been encountering the gritty, grotty bugs. Practitioners of this model hate to throw anything away, regardless of irrelevance. If it has been used before (under any circumstances), it might be used again — so include it as insurance against that possibility and/or just for completeness. New feature elements, or replacements to existing functionality, are added without the predecessors being removed. Sometimes this is done under the banner of “preserving backward compatibility,” sometimes out of ignorance, and sometimes from laziness. Occasionally the practice is institutionalised into a policy. Software developed under this model tends to exhibit a monotonic increase in size over time, leading directly to the observed behaviour of each new version requiring more disk, CPU, and memory resources just to lever itself into a running condition.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

  • Pages

  • November 2006
    M T W T F S S
  • RSS The Wayward Word Press

  • Recent Comments

    daveshields on SPITBOL for OSX is now av…
    Russ Urquhart on SPITBOL for OSX is now av…
    Sahana’s Respo… on A brief history of Sahana by S…
    Sahana’s Respo… on A brief history of Sahana by S…
    James Murray on On being the maintainer, sole…
  • Archives

  • Blog Stats

  • Top Posts

  • Top Rated

  • Recent Posts

  • Archives

  • Top Rated

  • %d bloggers like this: