Distrusting Beauty

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.


One Comment on “Distrusting Beauty”

  1. Marty says:

    You’ve expressed a core dichotomy of the programming experience very well, Alan. As a consultant who starts with the framework you (speaking generally) have developed and implementing it with a customers requirements in mind, I can say we experience a different, if similar set of conflicts.

    Full disclosure – I work for Guidewire as a consultant.

    So how to attend to a customers requirements without losing sight of the principles of maintainable development? When to abstract a bit of business logic that may only apply to a single field into an entity property? Are we taking too procedural an approach to this particular process-oriented requirement? Are we loading our pre-update rules with actions that would be better expressed elsewhere?

    We all know there are no simple answers to those questions. We strive to guide clients to implement their requirements in ways that are rational extensions of the out-of-the-box hierarchy and respect the local requirements of customers.

    In my personal experience, I’ve found very few instances where the choices Alan describes have constrained our implementation.

    I’ll finish with the same statement I’ve always used during interviews – Guidewire is, without question, the best product company I’ve ever worked for. Go Guidewire!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s