Software design

One traditional division of software knowledge-–into algorithms, data structures, and system design-–leaves out software design: interfaces, object definition, dependency structure, and so on. So, for example, not which database to use but how to use the database. Here are some resources on the subject.

To read

...And an exercise:

Sketch out the dependency graph for some fragment of your code base. Do this at both the "logical level" and the "code level" (as Koppel would put it), and don't conflate the two. Don't dismiss this as an elementary exercise: (i) it's rare to see it actually done (as usual, people rarely "do the reading") and (ii) I've never regretted taking the time to do it. Be careful not to conflate conflate data flow with the direction of a dependency. (Ousterhout warns us against "temporal decomposition," and I've found both the phrase and the warning useful.)


Home page