Homer, God and Beautiful Code

There's a new Riley book called 'Beautiful Code'. It full of, wait for it, code. And the code is supposed to be beautiful. It may well be beautiful. I can't tell. The code is written in half a dozen languages so unless you're the type of person who enjoys sitting up with Knuth's The Art of Programming instead of watching the Simpsons, you'll probably be no wiser than me.

But it does raise the interesting question about beauty. Generally a beautiful woman or a beautiful picture doesn't need the benefit of three years formal training to appreciate. Of course sometimes a great or beautiful wine does require a bit of training to appreciate. But even the dunces amongst us can quaff a Chateau Lafite or a glass of my best apple wine and say 'That wasn't a bad bit of plonk.' But a piece of beautiful code is just a bunch of symbols. A Perl programmer shows off his beautiful code and to me it looks like a cat walked across his keyboard. So where's the beauty?

Well perhaps it's in the shortness. Coming in at 5'6" I want to endorse the idea that short is beautiful. If that idea really catches on, my life will become undeniably pleasant. 'More wine, darling?' from a socially disadvantaged 6' 2" brunette trying to raise her status by being seen in my company. Money from DVDs giving posture lessons in stooping to Steven Segal; a whole new life.

Well sadly, it seems only to work for code and things like that. And even then, not always for code. Programmers sometimes have these strange contests (much of their life is strange) where they try to cram as much action into one line as they can. You can spin this out by using strange abbreviations for identifiers. But the result is humorous because its obfuscated code. Its like a parody of what beautiful code should be, because it takes one criterion of beauty, brevity, and elevates it to the point where it becomes grotesque. Rather like those female celebrities who choose to amplify their charms by implants which destroy all natural proportion, the charm is eventually lost.

All of which shows how elusive beauty is and how those who seize on one criterion of it, often end up destroying the very thing that they seek to create. Which brings us back to the question 'What is beautiful code?'

Now I believe that this is the wrong question. I believe that the real question is 'What is a beautiful solution?' Because if you answer that then you can answer the beautiful code question easily. Beautiful code is code that embodies the beautiful solution.

That doesn't mean that the language in which we write the solution has no impact on whether the code is beautiful or not; it does. A solution is a Platonic abstraction; it has no physical existence and it cannot be shared with others until it is rendered into some sharable form. The code clothes the invisible. The wrong set of clothes can mask a truly beautiful solution in the same way that a really ugly dress can spoil the appearance of a beautiful woman. Any solution written in BrainFuck or Malbolge will appear ugly. Contrariwise a beautiful solution written in a good functional language will appear chic, beautiful and elegant. Functional programming is to algorithms as the ubiquitous little black dress is to women's fashion.

Focussing on the nature of the beautiful solution rather than focussing on the code doesn't mean that the question becomes easier. It just means that you are asking the right question. That's often half the battle.

The Monkey and the Bananas

Problems and solutions are one-many related. In programming a problem generally has many solutions. The Doctrine of the Right Thing states that one of those solutions is the Right Thing - the best solution for the problem. So its not surprising that amongst the Knights of the Right Thing, there is a strong devotion to that elusive ideal of beauty. Its very much an MIT ideal, though happily it has spread. It echoes the Keats' motto that Truth is Beauty and Beauty is Truth. Getting it Right means making it beautiful and making it beautiful means getting it Right.

So what is the good solution; the Right Thing? Well, back in the days when psychologists were disliked for doing unpleasant things to rats, they arranged for an intelligence testing experiment where a monkey was placed in a situation where he had to make a pile of boxes to reach a bunch of bananas hanging from the ceiling. Getting it Right for the monkey means sifting through the space of possible solutions until he has assembled the right pile of boxes for getting the bananas.

The monkey-and-banana situation is pretty much the situation of the programmer approaching any significant programming task. The bananas are the goal of his programming, the specification of the task to be done. The boxes are the resources of the programming language which he must assemble into a pile of code which will eventually reach into the heavens where his specification is waiting to greet him. In the best case he will reach his goal on top of a few well chosen boxes. In the worst case, an unstable badly thought out stack of code will crash and dump him harshly onto the concrete of the debugger.

Generally this process of construction involves solving several subproblems - or manouevering certain boxes into place to continue the analogy and generally there is more than one path to that subproblem.We can abandon the monkey to his bananas at this point because what we're talking about is search; the classic AI paradigm.

The simplest search technique is just generate-and-test; that is grab the first available solution and walk with it. This may not be so dumb and for code monkeys under commercial deadlines this is what they actually do; 'Just code the frigging thing and ship it out' is the motto - a long way from the Right Thing. But, oddly, the fact is that this dumb and derided approach does have something profound inside of it which tells us something important about the Right Thing.

The truth is that the lowliest code monkey is smarter than just generate-and-test. He actually operates with an evaluation function. This evaluation function I'm going to call Homer's Rule (after my favourite cartoon character). The motto is:

Make it easy for yourself

Homie is pretty good at applying this motto. He actually leads a pretty comfortable life with this attitude of mind (and a lot of help from Marge). And here's another thing. Lowly code monkeys who crank out ill-understood and bug-ridden code and top programmers (you know, the guys who are supposed to write the beautiful code and earn big $) both use Homer's Rule. And since I'm writing this, you might guess that I endorse Homer's Rule in programming too.

Working With Homer's Rule

Homer's Rule then is about how much work you have to do to solve something. It doesn't tell you what problems to pick, but it does provide an evaluation function for choosing solutions to a problem. It tells you that the best solution is the one that makes life easiest for you. Homer's Rule works very well in the management of almost any project because in software engineering, CPU time is cheap (computers cost less and less) but BPU time (Brain Processing Unit Time) costs money. Paying for bums on seats that suck their pens and stare into space is not a good investment. Getting it done properly with no fuss is the thing.

Now at this point, you will find yourself experiencing a reaction. Racial memories inherited from deceased Sunday school teachers now reincarnated as CS professors and formal methods hacks saying 'No, don't listen to Dr Tarver, he has left the fold and will lead you into sin.' Or perhaps you will reflect on your own experience and consider how much effort your most beautiful code cost you in terms of thought. How can Homer's Rule tell us anything about the Right Thing?

First, I admit I have left the ongoing farce of formal academics. But I will insist that Homer's Rule will not lead you astray in your work. What will lead you astray is your own ability or lack of it. Its called brains and intuition. Its about how smart you are.

You see third-rate code monkeys who apply Homer's Rule and turn out a pile of diseased code that dies on the clients machine are not producing gunge because of Homer's Rule. They are producing gunge because they are not very good programmers. Producing sick code does not make life easy for you. It means that the client then gives sales hell down the phone. Sales then give your project leader hell. He then seeks you out and you have to spend a lot of time hiding in a cubicle in the gents toilets. Sick code that needs to be continually patched, will eat up your life and return to haunt you as surely as that ill-advised photo during last year's drunken office party.

To nutshell it we can say that

Homer's Rule + natural dumbness = bad solutions = diseased ugly code
Homer's Rule + acquired smarts = the Right Thing = beautiful code

Now we'll expand on that.

In the hands of a top programmer Homer's Rule leads to the Right Thing and beautiful code. Understanding this tells us something about the difference between a top designer and a barely competent code monkey. It turns out that the difference between the two can be characterised in terms of width and depth. The top designer thinks wider and deeper than the code monkey.

Explaining 'wider' and 'deeper' means returning to the AI paradigm. In classic search the solution space opens up like a tree from the initial start state. At each stage there are a number of possible ways forward, and each of them can be weighted according to Homer's Rule about least effort. Thinking wide means that you can hold many different solutions in your mind. This is good because it means that your mental space is more likely to include on the Right Thing - the solution that makes your work easiest. The diminishing end of thinking wide is generate-and-test - think of one solution and then stop thinking because its all too hard to figure out. This is not likely to lead to the Right Thing.

Thinking deep means being able to look deep in the search tree to see beyond the obvious. Maybe the obvious next step has hidden deficiencies which will only appear further down the line. This is the thinking characterised by adversarial algorithms like Minimax. Being able to see the snags before you hit them is a plus in any project. In fact the mind of the top designer is very similar in abstract to the mind of the chess grandmaster.

Being imperfect and limited human beings we can't expect to hold the whole development tree in our minds. If we could always do that we would occupy the farthest extreme away from the code monkey. We would have the intellectual faculties credited to God by theologians. But extrapolating to the limit does actually provide us with a definition of the Right Thing and its admirably short.

The Right Thing is what Homer would suggest if he were God

Mark