Open Discussion Thread for "The Cognitive View: A Different Look at Software Design" by Robert L. Glass

I'm excited about publishing this classic essay by Robert Glass--not only because I've been an admirer of his writings, ideas, and insights for a number of years, but also because it serves as an excellent launching point for a number of discussions, including the prescience of some of Glass's suggestions for "the future" (which is now here):

1. Modeling and simulation packages to support the mental process.
2. Idea archive and retrieve packages to prevent thoughts from falling through the cracks.
3. Strategic assumption surfacers that keep track of key requirements and pop them up when a candidate design is about to violate one.
4. Issue-based conflict resolution support.
5. Unresolved issue recording/tracking.
6. Mediated discussion support.
7. Group idea collection and coordination.

The timing of this publication is also perfect in the sense that I see this essay as the other side of the same software design coin addressed in the Jack Reeves "What Is Software Design?" essay, which was published in developer.* Magazine last month.

Where Reeves makes a definite point to address only the final product called "the design," Glass does just the opposite, foregoing discussion of the noun "design" to focus instead on the verb--that is, the cognitive (and social) process of design. The two essays are remarkably compatible. For example, Glass appears to implicitly agree with Reeve's assertion that "a program listing is a document that represents a software design" when he writes:

"Languages aren’t design; they’re representations for writing down the design once we get it."

Although, I think Reeve's goes further than Glass when he further asserts that programming is an essential design activity, part of the overall process of design; programming is not something that takes place after a separate "design activity" is finished.

Thanks for reading. I welcome your thoughts.

Dan

Gone with the Wind, Hitchcock's original Psycho, It's Wonderful Life, Twelve Angry Men, ... There are some classics that just keep impressing generation after generation. Dan, thanks for providing a platform for the IT equivalents. I love Hitchcock's strategic shadows, and certainly see the continued validity of Glass's observations. I've long noted (when reflecting on current staff and approaching a hiring decision) that a "quick-witted" person was the most useful when it came to problem-solving and design (and design is problem solving, as Glass asserted).

I especially appreciated this comment:

"...The study of software was at least as much about studying programmers as it was about studying programs."

It's so true that most problems that arise surrounding software development are sociological, not technological.

Developer.* is really shaping up to provide rich diversity in content and I feel sure it will soon command the audience it deserves.

What were those steps?

The designers, mentally and at lightning speed, were doing the following things:

I found a website (Visual-Spatial) lately which tends to explain the "lightning speed" as the result of performing visual-spatial (related: imaginative, no-rules) as opposed to autitorial-sequential (related: communicative, rules) way of thinking, the "mentally" keyword.

I found this website very interesting and also rather relieving as it tries to develop a lot of empathy for both ways of thinking and also points out that our society is more based on communication and rules while as a software engineer I can identify much more with the "other world" for my working style.

A last comment to resolve the play with the words in the subject: "Right" refers to "left" and not to "wrong" (though the latter might point to certain misunderstanding between project managers and software developers;-))...

Dark Horse

I try to teach software design as part of my software engineering course. While I applaud Prof. Glass’ essay, I fear it will let too many software professionals justify their lack of education in analysis and engineering.

I make these distinctions: Architecture is synthesis and design is analysis. Program designers must learn how to do feedback control, finite state-machine, Markov chain, refactoring, reliability analysis, economic analysis, to name a few. The goal is to perform design simplification during the architecture phase by reducing the number of function points by 20% that will be implemented. Designers can do this by:

1. Reusing working components or subsystems.
2. Eliminating or trivializing features.
3. Dropping features that do not align with the Measurable Operational Value for the project.
4. Refactoring.
5. Approximations to simplify algorithms or equations. For example, never average; but use a fading memory polynomial filter instead.
6. Structure components through design constraints that limit options.

There is more of this in my new book. I insist that the prototypes be kept alive throughout the projects so that they become models to test emerging designs.

Prof. Glass is correct that synthesis is a mental process and that the artifacts of design are just tools to help the process.

To this I add the need for Trustworthy Design. This is my response to a recent letter in Scientific American:

The article in your March 2006 issue, "Software Insecurity" comes close to defining the problem of having untrustworthy software but missed the mark. Entirely domestically produced software can be, and too often is, just as untrustworthy software produced outside the US. We needed 'Trusted Software Shops,' as much as 'trusted foundries.'

I am urging that the software industry produce trustworthy software meaning that the software is Safe, Reliable and Secure. This is the next major area in that demands academia and industry attention - both for national security reasons as well as a way to ensure that the U.S. software industry continues to maintain its leadership.

Software system development is too often focused solely on schedule and cost. Sometimes performance and functional technical requirements become an issue. Rarely is trustworthiness considered. Not only must software designers consider how the software will perform they must account for consequences of failures. Trustworthiness encompasses this concern.

The global software industry seems exempt from the need to practice due diligence and from liability suits. The underlying problems with software trustworthiness is not technical, it is the legal and business structure of the software market. This exemption slows the adoption of trustworthy technology. The state-of-the practice lags the state-of-the-art by a wide margin. There are few financial consequences to companies that produce poor software; but there are survival is at stake for companies that are slow to market. The software industry has been operating in a 'customers beware' market structure. Corporate fraud has stimulated the call for corrective action. The Sarbanes-Oxley Act (SOX) is driving a renewed interest, and corporate expense, in trustworthy software. Enterprise incentive management software must enable the financial control cleanup required by Sarbanes-Oxley Act Section 404.