04.24.07
Review: Ko's A framework and methodology for studying the causes of software errors in programming systems
I’m reading A framework and methodology for studying the causes of software errors in programming systems by Ko and Myers that classifies the causes of software errors, and there is a diagram (Figure 4) that I’m really taken with. They talk about there being three different kinds of breakdowns: skill breakdowns (what I think of as “unconscious” errors, like typos), rule breakdowns (using the wrong approach/rule, perhaps because of a faulty assumption or understanding), and knowledge breakdowns (which usually reflect limitations of mental abilities like inability to hold all the problem space in human memory at one time).
Leaving out the breakdowns, the diagram roughly looks like this:
| Specification activities | ||
|---|---|---|
| Action | Interface | Information |
| Create | Docs | Requirement specifications |
| Understand | Diagrams | Design specifications |
| Modify | Co-workers | |
| Implementation activities | ||
| Action | Interface | Information |
| Explore | Docs | Existing architecture |
| Design | Diagrams | Code libraries |
| Reuse | Online help | Code |
| Understand | Editor | |
| Create | ||
| Modify | ||
| Runtime (testing and debugging) activities | ||
| Action | Interface | Information |
| Explore | Debugger | Machine behavior |
| Understand | Output devices | Program behavior/td> |
| Reuse | Online help | Code |
I’m a bit fuzzy on what exactly the reuse “action” is, and how “explore” and “understand” are different, but in general, it seems like a good way to describe programming difficulties. I can easily imagine using this taxonomy when looking at my user study.
