Making Software is like: Solving an Excessively Difficult Wooden Block Puzzle
I’ll warn you now, this post is much more rambling than usual; I am a bit out of practice and I am trying to tackle an issue that is still a bit ill-formed in my own mind. I want to discuss the fault-based nature of the software design process. Why do we seem to describe a software design more in terms of what it does wrong, than what it does right?
In my pen-and-paper maze post, I explained that software design seemed like it was about bumping into problems and adjusting, rather than plotting a course and following it. I emphasized that the problems were often difficult to foresee. I think this is true, but I want to elaborate on it, because I am increasingly thinking that this is central to the difficulty of software design.
Consider a given design, whether it is a blueprint of a building, a spec of a product or a software design document; the object described has its strengths and weaknesses. The blueprint might specify a building that is majestic-looking, will provide a great deal of useful space and will be inexpensive to produce. But it might be susceptible to earthquake damage, or violate a local building ordinance. Every designer tries to maximize the positive aspects of his or her products, while minimizing the negative. But is this especially difficult in software? It feels like it – it seems to me that the negative consequences of a design are difficult to anticipate, and difficult to fix, compared to other fields.
The first aspect of this is the inevitability of problems in software designs, that is, the difficulty of foreseeing problems and avoiding them in the first place. In some fields, the sorts of problems that might befall a design are often easy to understand beforehand, internalize and use to intuitively guide the design as it progresses. It’s an oversimplification, but we might consider the major problems that an architect’s design might have to be: structural instability, failure to provide enough space of the necessary kinds, and aesthetic unpleasantness.
The first of these is intuitive to the architect he will rule out and design paths that would cause structural problems without even thinking about it. He can then think about the types of rooms that are needed (meeting spaces, bathrooms, hotel rooms, whatever) and begin to compose frameworks of ideas that incorporate these needs. He might consider the necessary rooms to be building blocks to be arranged, and can then focus on assuring himself that the final concern, aesthetic pleasantness, is met. As each possible problem is considered, it can be internalized, and used as a set of constraints that will frame the next phase of the problem.
But in software, there are countless things that can cripple a given design. It might be too slow, too difficult to understand, too difficult to maintain, have modules that contain too much functionality, have overly complicated interfaces, fail to provide the needed functionality, make bugs difficult to find, and so on and so on. I am of course, being more meticulous here, which makes the architecture comparison a little unfair, but bear with me.
The problem is that there are numerous concerns, and it is very difficult to internalize one and thereby focus on the others. I’m sure others have covered this ground (wicked problems?) but the problem seems to be that these failures of a design are emergent, they only crop up as the consequence of several interacting parts, their creation is not predictable and doesn’t adhere to intuitive rules. And the number of possible concerns means that focusing on one or two leaves plenty of others to stumble into. There simply isn’t a way to design with all the possible pitfalls in mind. This might explain why much of the software design I have been exposed to has consisted of designers sketching out a design, standing back from it, pointing out the problems, and adjusting. There is no room to make a design that is innovative or beautiful or amazing, they are just simply trying to work their way to something without glaring flaws.
The other problem is the interconnectedness of software problems (once again related to the concept of wicked problems). Whenever we adjust one aspect to fix one problem, it is very easy to introduce others. The result can be frustrating. I won’t venture that this is more a problem here than it is in other design fields, but it compounds the difficulty in software’s seemingly inordinate level of problem inevitiability. (This is related, in my mind, to a different angle on puzzle games, but I will come back to that in my next post, perhaps.)
And finally, of course, the abstraction and unpredictability of software design means that some problems simply can’t be found until you have compiled the program. And even then, linking problems seen in running programs back to their sources in the code, let alone module-level design, can be terribly difficult. These are pet points I have beaten to death elsewhere, if not in this blog, so I’ll leave them for now – but they present yet another level of difficulty.
I started off with the question: “Why do we seem to describe a software design more in terms of what it does wrong, than what it does right?”. I’m not sure I have the answer, but I think the problem is that there are so many ways we can go wrong, that we will take anything that works. We can’t appreciate the beauty of something that is this hard beyond the fact that it works. If we saw a software design that was truly appealing, we might even distrust it, given our prejudices that such things are supposed to be workhorses.
I don’t think there is such a lack of joy in many other design fields. Architects, fashion designers, graphic designers, product designers, and I suspect even process designers and mathematicians are able to look at others’ designs and get joy from them. They can really appreciate exceptional designs.
I can liken a design to one’s process for solving a wooden puzzle. It’s a bit of a weird metaphor, because I am comparing the actual design result to your own process for solving the puzzle, not your appreciation for the puzzle itself, but bear with me.
Do you enjoy a given design? That depends on how many good, clever, beautiful ideas are in it, versus workarounds to simply make the thing work. Similarly, when a wooden puzzle is just hard enough, the process of solving it can be very satisfying. You start to gather information about how it works and feel smart, and you get stuck, but not so often that it kills your good time. Afterwards, you can look back on the solution, perhaps repeating it, and see all the nice tricks you used to make sense of the thing. This puzzle hit that sweet spot for me nicely, as did this computerized puzzle game.
I liken software to the process for solving a puzzle that is just too damn hard. You are so burdened with interlocking interrelationships that it becomes work. You are often more relieved than you are excited when you finish it. You may look back on your process with pride (as a software designer might look back on his or her work), but it probably won’t be a sense of joy (I’ll use this excuse to link to some really amazing puzzles that look really difficult, though they might still be satisfying to solve - video too).
Of course, maybe I am just not experienced enough. Much as the Rubic’s cube seems utterly unknowable to most, there are some who have penetrated its mysteries and find it to be a very satisfying process. In this case, we should find ways to make software more readily appreciable, I would argue that the curve for its true appreciation is much too high. Not sure how to tackle that just yet, though 
Finally, I’ll touch upon a possible alternate explanation for software’s ugliness:
Each of my examples of joyful designs is a product that is viewable and appreciable by the public at large. There is an incentive for the designer to make something that is beautiful, as well as functional. Software designs, meanwhile, are hidden behind the curtain of compilation. What use is there in creating a beautiful design is no-one will ever see it? Better to just create a beautiful interface and some business code that will ensure that technical problems don’t get in the way. Its not that software design is a thornier process, it’s just that its beauty is hidden, and therefore (quite reasonably) neglected.
There is definitely some nugget of truth to this; designs would be prettier if anyone would ever appreciate them. But I still think that the process of software design is so riddled with possible problems and difficulties that it is difficult to imagine someone making an amazing design, one that really brought joy to the creators and observers, rather than an admiration of its lack of flaws.
Software is workmanlike stuff. Maybe it shouldn’t be surprising that it is not attractive. But I think this has a negative effect on those who create it, and I want to try to find out what that effect is, and how it can be diminished.
