Communications of the ACM

Practical programmer

Software Design and the Monkey's Brain

By Robert L. Glass
Communications of the ACM, June 2008, Vol. 51 No. 6, Pages 21-22
10.1145/1349026.1349031
Comments

There has been a lot of brilliant software engineering research over the years and decades into the subject of software design. That's the good news. But then there's the bad news.

The bad news is that all of that brilliant research hasn't enhanced our knowledge of how to do software design in practice. It's like we now have a really good handle on the philosophy of design, and the reality of how to do design well. But that hasn't helped us tell practitioners how to be better designers.

My interest in design, and my belief in the work of software engineering researchers on the subject of design, began over 20 years ago. At that time, Bill Curtis was leading a team of researchers at the former Microelectronics and Computing Consortium (MCC) in Austin, TX, and Elliot Soloway was conducting similar work at Yale University. The goal of these two efforts was to investigate the nature of software design in order to figure out how to do it better. The expectation, especially from Curtis and his team, was that the result of their investigation was going to be a set of processes—probably tools—that could be provided to software practitioners to help them do their job so much better.

The investigations were very successful. By studying expert designers at work, the researchers learned that the essence of software design was a sophisticated trial-and-error activity:

• Develop a complete understanding of the problem to be solved;
• Build a mental model of a proposed solution to the problem;
• Mentally execute the model on a sample input to see if it does indeed solve the problem;
• If the output of the execution is incorrect (as will often be the case in the early stages of design), expand the model to correct the deficiencies, then execute again;
• Once the output of the execution of the model is correct, choose a different sample input and repeat the process; and
• Eventually, the expectation is that a strongly enhanced mental model will be able to solve all of the sample inputs considered.

(To find a more complete discussion of this process and its ramifications, read any of the circa-1980s writings of either Curtis or Soloway, or see my discussion in my recent book Software Creativity 2.0 (that discussion is found in the chapter "Creativity and Software Design: The Missing Link").

Now, all of that understanding of design that Curtis and Soloway produced was almost monumental in its scope. We now understood, in very believable ways, that software design as practiced by its experts was a trial-and-error iterative process. This may not have been a terribly acceptable discovery to computer scientists who presumably had hoped for a more algorithmic or prescriptive approach to design, but to software designers in the trenches of practice, it rang a clear and credible bell.

That summarizes the mostly good news I mentioned in the first paragraph of this column. But now here's where the bad news takes over.

As I mentioned, it was the expectation of Curtis and company that, once they learned the true nature of software design from their studies, they would then package some kind of design solution approach (be it process and/or tools) and pass it on to practitioners. In fact, that was the rationale given for the funding that allowed those wonderful research studies to be conducted in the first place. The MCC would be known, throughout the software engineering world, as the place to go for help in solving the problems of software design.

But it didn't work out. Remember that essence of design, the iterative process, I discussed earlier in this column? Well, all of it happened inside the mind, at the speed of human thought. Attempts to enhance the iterative process, such as by jotting down notes or even using computer-based tools, simply slowed the process. The mind could do things much faster than the hand could record its workings, and speed was of the essence in that highly iterative, somewhat complicated process.

I remarked at the time that what we needed was a mind amplifier, a computer-based tool that could record all those wonderful workings of the mind as it went through that iterative process, and convert what it recorded into the results the mind would eventually produce. Big HA! No such tool was available, even in the minds of the artificial intelligence scholars of the day.

My computist-in-training son even envisioned a solution, based on my imaginings, of a mainframe computer on wheels that would be hard-wired into the mind of the designer and would follow him around. Even bigger HA! The idea was as laughable then as it is now.

But wait! A recent issue of ACM TechNews included the headline "scientists use monkey's brain signals to control robot" [1]. The author of that article, and the scientists who had conducted the research, were excited about the prospect of using brain signals to control robots, so that—for example—paralyzed people might be able to use their thoughts to move their bodies.

And that's a hugely laudable application of such a technology. It could be life-enhancing in unimaginable ways to paralytic or severely motor-impaired individuals.

But I couldn't help but think back to the dreams of Curtis and Soloway, and mine, and even my son's, to provide computer support for the software design process. Like so many other wondrous applications of computers over the decades, we may at last be on the verge of finding a way to transfer those design discoveries of Curtis and Soloway into something the practitioner software designer can actually put to use.

I'm not holding my breath, but I find the prospect pretty exciting. Perhaps all that big HA stuff will not be so funny after all.

Back to Top

Back to Top

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2008 ACM, Inc.

---

No entries found