I collected responses from six groups to three questions: what are the most important things you have learned, in what areas do you want to get better, and what are the markers of software quality.

Things learned

Four of the six groups mentioned the design recipe at or near the top of their lists:

Two groups put high priority on problem-solving skills; a third group had this skill as a lower priority:

Several groups felt they had gained important skills that relate to particular aspects of design recipes. First, data definitions and analysis:

Next, examples, especially functional examples:

A couple of groups mentioned templates:

Toward the lower end of people’s lists of things learned, there is more diversity:

Wanting to get better

When I look over the areas in which people want to get better, there is much more diversity. My commentary is in italics.

 

 

 

 

 

 

 

 

 

Markers of high-quality software

You identified several different kinds of markers. I’ll begin with down-to-earth, technical properties that you can expect not only to be able to recognize, but to be able to build in.

You also identified some properties that are usually easy to recognize but can be quite hard to build in

You identified some more properties that are also solid and technical, but which can be difficult to recognize. For example, to tell if tests are “comprehensive,” you would have to have a deep understanding of all the relevant data definitions:

You also identified some properties that sound good, but that you can’t really check for yourself. These properties can be evaluated or recognized only by very expensive experiments that involve having an outside expert read the code. These properties are nice if you can get them, but because they are so expensive to evaluate, I wouldn’t aim for them—I would aim for properties you can recognize at reasonable cost.

You identified a few properties that I think are risky or misleading. You will have to decide for yourself. My commentary is in italics.

Finally, you identified a few properties that I think are irrelevant, off, or downright wrong:

Markers of low-quality software

You identified properties of low-quality software which are, unsurprisingly, related to the properties of high-quality software that you identified. Rather than provide a similar breakdown and analysis, I’m just listing the properties, followed by a little commentary.

I find little to disagree with here, except possibly “extremely expensive operations” or “runs slowly.” Speed is not an absolute good, and slowness is not an absolute bad. It affects our perception of software quality only when software is not fast enough. Here’s a real-world example:

Here are a few more followup points:


  1. Someone has taken COMP 11.

  2. Your instructor thinks this is an impossible path toward structure.

  3. Exception made for designing interactive graphics programs with big-bang; for that, refer to the Design Guidelines for big-bang Programs.

  4. Complexity is almost never necessary.

  5. Hint: the size of the compressed backup was 840KB. In case you don’t usually sling around KBs and MBs, before compression, the backups needed around 880,000,000 bytes of storage, and after compression, they needed about 860,000 bytes of storage. What do you imagine I think about the quality of lzma?