Abstractions in Design

Peter Torr from Microsoft blogged that Changing Abstractions in an Object Model is Hard. I think of system design as the "art" portion of software development. I consider a "programmer" as a person who is familiar with the technical (both normal and arcane) details of an operating system, language, or framework. The "software developer" needs to know the former, and branch out from there, thinking of object models, end-user usability, threat models, abstraction, and extensibility.

The italicized font portions below are quoted from the blog entry (some liberty with snipping was taken for readability out of context). If you are interested in learning more about solid design, this essay is a good high level overview. These are (IMHO) the salient points of the essay:

But to make a[n] object model easy to use, you want to simplify (abstract away) many of the details so that the developer has less concepts to understand and so that they can "discover" and use the features of the object model in a natural way.

...you don't want to make your system more complicated than it needs to be. Complications lead to bugs, and unnecessary complications lead to unnecessary bugs. Having lots of "pluggable" components (interfaces, abstract classes) makes it hard to reason about the system (and to threat model it!) because you can't be sure what any given extension will do.

Or, if she is just getting started with the object and starts to read the conceptual overview, there will be far too many things obscuring the basic design that she won't be able to see the forest for all the trees. This is a real concern, since documentation is incredibly hard to write and minimizing the number of concepts a developer must grasp to use an object model is crucial to making it usable.