Practical Programmer

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 main-frame 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. c

REFERENCE

1. Gaudin, S. Scientists use monkey’s brain signals to control robot. Computerworld Careers (online), Jan. 16, 2008; www.computerworld.com/action/article.do?c ommand=view- ArticleBasic&articleid=9057319.

 

ROBERT L. GLASS ( rlglass@acm.org) is the publisher/editor of the Software Practitioner newsletter and editor emeritus of Elsevier’s Journal of Systems and Software. He is currently an honorary professor in the ARC Center for Complex Systems at Griffith University, Brisbane, Australia.