Partially Examined Software Design Philosophy

[Editor's Note: This is a guest blog from our supporter Michael Rissman. Enjoy!]

Philosophy doesn’t make me a better software designer. It does help me reflect on what I do when I am designing. A few podcast episodes are germane here: the ones on Pirsig, Wittgenstien and Goodman. Donald Schön in The Reflective Practitioner: How Professionals Think In Action described design as a process of naming and framing, and that’s an excellent place to start.

Consider one aspect of an information system. Users search for things satisfying certain criteria: for example, authors who wrote mysteries with no violence in them. Results can be presented in a grid with rows representing found instances and columns displaying attributes of those instances. An information system I developed comprises 104 such grids. I know that there are 104 because I implemented each the same way using metadata which I can query to obtain the count. But what if I hadn’t performed the ontological act of naming the search-result-grid as a class of things? The system would still manifest a number of grids showing results, but I would have to identify the set of such things extensionally, by naming the instances rather than intensionally by class.

Object-oriented analysis is all the vogue in software design. Its proponents advocate orienting information systems around the things in the world to which the information applies: books and authors and the like. My stance is to view an information system as a processor of patterns of data. That leads me to see search-result-grids and edited-text-fields and other classes the behavior of which can be described in metadata. The patterns of data transcend object-orientation and are obscured when the objects are allowed to be transcendent.

My design comprises a language game in which classes like search-results-grids and edited-text-fields and edit-logger make full sense. The language game provides context for other system aspects such as connectivity and synchronization and security and the like. My goal as a designer is to untangle a lattice of interactions so that the resulting composition seems hierarchical and thus compatible with classical rationality. Systems designed that way evolve wonderfully if allowed to do so.

How did I know to play the processor-of-patterns-of-data language game? I’m smart and lazy and had opportunities to design systems as I saw them. I could trace the evolution of my design but eventually would hit a point where the rest was “pretty much turtles all the way.” The point is that classical rationality does not stem from a rational process. Great designers make tractable worlds and tractable worlds comport with classical rationalism. They play language games, naming things and framing them as they go. The languages they create are structured and generative.

As language game players, designers are also world makers. The worlds they make are akin to scientific theories, theories that can be tested much like Goodman suggests. One can ask questions of a designer’s ontology: Is it expressive enough to satisfy users? Does it scale well? Can its elements be built?

I started with a case of name dropping and I’ll end with another. Fred Brooks who got much about software wrong, got one thing right. He wrote that conceptual integrity is the most important software quality. Conceptual integrity is the notion that a system does the same thing the same way everywhere: presenting all search results the same way for example. At scale, conceptual integrity is the sine qua non of software system quality. The system designer sits at the head of the train. Quality resides in the language game he decides to play.

-Michael Rissman

by