This month, I read most of Zen and the Art of Motorcycle Maintenance and some of the Design of Everyday Things. I couldn’t quite finish either of them before time ran out and they were due back to the library. With that said, I think I got a good feel for what each author was saying overall.
Both books delve into the relationship between objects and people. In Zen of Motorocycle Maintenance, the author views objects with reverence. For him, a motorcycle is a dynamic being. He observes and responds to it. As it strains from overuse, he reduces the speed of the bike so it can recover. He is attuned to any signs of failure and promptly works to correct issues. The limitations of a motorcyle, such as overheating, are not strictly design flaws. They are bounds in which the object can work well. If you place the object out of bounds, you can not blame the bike for coming up short.
In the Design of Everyday things, the author was much less forgiving of the object. Objects provide some utility and give some hints as to how a user may access that utility. For example, a door provides the utility of transit into a building. Its door handle will have a certain shape that indicates to the user whether you should push, pull, turn or slide to open the door. If the user of a door cannot easily deduce how the door should be used, the blame is on the door, or the designer of the door. It should have been made in a way that would make things easier for the user.
I wonder how the authors of these books would feel about the other book.
I sympathize with both camps. As a software developer, it’s good to think like the author of Design of Everyday Things. You want to make things that are generally easy to use. Any confusion can lead to user errors and overall dissatisfaction. So, you have to put yourself in the mind of the new user and guess how they might feel about your product or API. Is the most natural way to use your product also the correct way and also the easiest thing to do? Telling people to read the manual is a signal that the design can be improved.
As a software developer, it’s also good to think like the author of Zen of Motorcycle Maintenance. You need to observe and be attuned to your code. If it misbehaves with bugs or bad performance, you can’t just blame the original authors and say the design is poor. You have to foresee or at least react to issues. Each bug is an opportunity to understand your system a little bit more and improve your system to be a little more robust.
In total, while I see the merits of both, I think I lean towards the Zen of Motorcycle philosophy. What about you?
Top comments (0)