There is a characteristic of software that you’ve perhaps not thought of and which perhaps should have some influence over the design of programming languages and certainly of software methodology. It is habitability.

Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.

Habitability makes a place livable, like home. And this is what we want in software—that developers feel at home, can place their hands on any item without having to think deeply about where it is.

I’ve heard Gregor Kiczales—one of the CLOS designers—say that he wishes that computer science practice could reach the level of engineering excellence that creates buildings like the Superdome in New Orleans. He points out that the design of the Superdome puts together pieces made from a variety of materials and from a range of engineering and building disciplines. The result is a monument to that engineering skill. This is a tempting picture, but I think it’s off base.

Buildings like the Superdome lack habitability. In this instance people inhabit the building, but only for very short periods of time, and for very special occasions—and such buildings are not easily grown or altered. The Superdome is a static building, and therefore it can stand as a monument, being little else.

A modern skyscraper, to take another example, has a fixed inflexible interior, which is secondary to the designed beauty of the exterior. Little attention is paid to the natural light, and often the interiors are constructed as “flexible office space,” which means cubicles. The flexibility is for management to set up offices for the company, not for the inhabitants—the employees—to tailor their own space. When you run out of space in the skyscraper, you build another; you don’t modify the existing one or add to it.

Contrast this with the New England farmhouse. It starts as a small home with a barn out back. As the family grows and the needs of the farm grow, a back room is added to the house, then a canning room, then a room for grandma; stables are added to the barn, then a wing for milking more cows. Finally the house and barn are connected because it is too difficult to get from the house to the barn in a blizzard. The result is rambling, but each part is well-suited to its needs, each part fits well with the others, and the result is beautiful because it is a living structure with living people inside. The inhabitants are able to modify their environment because each part is built according to familiar patterns of design, use, and construction and because those patterns contain the seeds for piecemeal growth.

I think this should be the goal for computer science practice. Most programming languages are excellent for building the program that is a monument to design ingenuity—pleasingly efficient, precise, and clear—but people don’t build programs like that. Programs live and grow, and their inhabitants—the programmers—need to work with that program the way the farmer works with the homestead.

What are some of the things that contribute to uninhabitable programs? Overuse of abstraction and inappropriate compression come to mind..

comments

  
Kartik Agaram, 2016-09-19: Some anti-abstraction links to pile on to that tantalizing ending:
"The wrong abstraction"
"Write code that is easy to delete"
"Abstraction considered harmful"
"An alternative worldview to 'modularity'"
"Disadvantages of code reuse"
"DRY and the cost of wrongful abstractions"   
Kartik Agaram, 2019-02-15: "On the other hand, people need a chance to identify with the part of the environment in which they live and work; they want some sense of ownership, some sense of territory. The most vital question about the various places in any community is always this: Do the people who use them own them psychologically? Do they feel that they can do with them as they wish; do they feel that the place is theirs; are they free to make the place their own?" — Christopher Alexander   
Kartik Agaram, 2021-09-04: Thanks to a comment on "Mu's neighborhood", I'm reminded that "Seven Laws of Sane Personal Computing" is an attempt at analyzing habitability and Christopher Alexander's related notion of the Quality Without A Name (QWAN)   
Anonymous, 2021-10-15: This is quite apt.

Comments gratefully appreciated. Please send them to me by any method of your choice and I'll include them here.