Distrusting BeautyPosted: February 25, 2010
A few weeks back, a co-worker of mine sent around a link to Jonathan Edward’s blog post about the book Beautiful Code (http://alarmingdevelopment.org/?p=79); if you haven’t yet, read that post first, since it discusses the general subject better and more concisely than I ever could. The particular bit I think is most worth expounding upon is at the end of the post:
Another lesson I have learned is to distrust beauty. It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude.
As programmers, we’re constantly required to walk the fine line between, on the one hand, recognizing things that seem too ugly or not quite right and fixing them so as to prevent future problems and minimize complexity, and on the other hand leaving code alone so long as (we think) it works and moving on to something more important. There’s no obviously right setting for that dial; crank it down too low and your code base devolves into an unmanageable mess, crank it up too high and you never ship or you ignore real-world uses that don’t fit into your design.
At Guidewire we’re both blessed and cursed to be working on software for an industry that is so deeply rooted in the real world: cursed because the real world with all its laws, regulations, historical precedents, and regional differences often makes a clean design impossible, but blessed in the sense that having to solve real problems helps disabuse us of some of the ivory-tower-perfectionism that can often infect even the best developers.
People are drawn into computer science and programming in two very different ways (among many). Some people are drawn in by the joy of making things; they enjoy tinkering and trying things out, and they enjoy the end result of being able to make a computer or a system do something that it didn’t before. It’s the same fundamental impulse that draws people to most kinds of engineering. There are also people, and I fall into this camp, that are drawn to programming because of the abstract purity of its expression: it is, essentially, the reification of abstract ideas, an intellectual playground where not only do you have immense freedom to design and deconstruct and rebuild things in a thousand different ways, but even better your ideas actually come to life at the end. That particular impulse is much more the sort of thing that draws people to wholly intellectual pursuits like philosophy or mathematics. From personal experience, I can tell you that most philosophy students and professors are just as obsessed as programmers can be with finding an elegant solution to a problem, and are often just as blinded by that search for beauty and just as dismissive of the holes that reality pokes in their constructions.
I don’t think coming from either direction or impulse necessarily makes you a better programmer; it just makes you a different programmer, with different strengths and weaknesses. If your primary drive is to tinker and create, you might need to temper that with more concern for overall design and long-term stability, instead of just trying to get something working; if your primary drive is to create something intellectually beautiful, you might need to be more accepting of the ugly and arbitrary nature of real-world problem spaces and be willing to ship something even if it’s not perfect.