Zen and the Art of Software Design
I am currently reading Zen and the Art of Motorcycle Maintenance by Robert Pirsig and it has been chock-full of philosophical insights. One passage in particular jumped out at me due to its simple, but powerful, message:
The material object of observation, the bicycle or rotisserie, can’t be right or wrong. Molecules are molecules. They don’t have any ethical codes to follow except those people give them. The test of the machine is the satisfaction it gives you. There isn’t any other test. If the machine produces tranquility it’s right. If it disturbs you it’s wrong until either the machine or your mind is changed.The test of the machine’s always your own mind. There isn’t any other test.
This quote from the book could relate to almost any field involving technology, but it strikes a particular chord with me in regards to software design and development.
One way this quote can be looked at is an explanation of why a software engineer chooses and, almost more importantly, not chooses a tool for a particular task. We’ve all seen the flame wars that erupt on blogs and message boards about Tool A vs Tool B. Usually each of these pieces of software was developed to fill a specific need for a particular person whose needs were either not fulfilled by existing tools or the existing tools didn’t fit their world view. These original creators were creating “tranquility” for themselves.
When software is created for the reason of creating peace of mind in the developer, the result is often that a tool that doesn’t feel right to them is getting replaced. An example of this is the new web frameworks that have sprouted up over the past few years, mainly Django and Rails. The creators of these pieces of software dreaded the ordeal of writing yet another website or web app in Java or PHP because to them these methods didn’t produce tranquility and just felt wrong for the task at hand. So these developers wrote something that felt “right”.
Since both Rails and Django ultimately were fulfilling the same purpose, other developers that wanted to go down the path of rapid web development had to choose between these two. On the web, whenever there is no clear advantage of one technology over another, conflict arises. You have people entrenched on both sides of the debate of which technology is better. What is not seen is that neither side is inherently right or wrong. Rightness is only determined by what creates tranquility in the person using the tool.
If you like Ruby and the Rails way of doing things, go that way. If you enjoy Python and the Django method, go with that. The main goal is not to choose some arbitrarily correct right tool, because what may be the bee’s knees to one developer may be chopped liver to another. It’s usually not that extreme, but the point is that often arguing over particular technologies is like arguing over favorites colors. The only winners are the ones that choose the tools that suit themselves the best.
3 Comments