The three banking programmer virtues

Larry Wall, the designer of perl, says that the three great programmer virtues are laziness, impatience, and hubris. (Oddly, the top google hit for "programmer virtues" is on open.nit.ca. I'm honoured, but that's not actually a very good link. Use this one instead.)

While talking to dfcarney today, I was trying (again) to explain the difference between the kind of programmers I'm used to dealing with - let's call them "hackers" - and the kind of programmers that made the banking software at Pacific & Western Bank, which is where the initial Versabanq products come from.

Most programmers and most software companies, whether banking-related or not, are crud. That's because 90% of everything is crud. Let's discard that 90% for now.

The banking programmers I'm talking about are actually good at what they do. But they're also nothing like the "hackers" I'm used to dealing with. It occurred to me today that this is because the things that make you successful at writing business software are the antithesis of the three programmer virtues. Business software developers don't have laziness, impatience, and hubris, they have diligence, patience, and humility.⁽¹⁾

Laziness is about finding an efficient way to do something so you don't have to do it over and over. But business rules are complicated (being invented by politicians), and often a generalization is harder to understand and maintain than a simple enumeration of the details. Instead of being lazy and thus more efficient, you're diligent and thus more precise.

Impatience is about wanting the right solution right now, and getting annoyed when the computer is being too lazy to give it to you. But most successful businesses, to the dismay of Web 2.0 companies everywhere, are slow and boring and conservative - and patient. For a bank, doing the wrong thing right now would be deadly; patiently doing the right thing in five years will make you such huge profits that it'll be worth the wait.

Hubris is about believing you can do a better job than everybody else, and thus being willing to take the risk of doing things differently in the hopes of doing them better. But financial systems are complicated, and programmers rarely have the expertise to define those systems by themselves. They need to have the humility to admit that actually, in business software, most of the time it's someone else who has the answer.

Thinking of it this way, you can begin to see why so much excellent genius-powered software is terrible for business, and why so much useful business software seems to be so inefficient.

It's a classic compromise situation, and you know how much I hate those.

In fact, it might be the most important compromise in all of computer programming. Wouldn't it be cool if there were a solution?

Absurd Footnote

⁽¹⁾ I did a search for these terms to see what came up. How ironic: Larry Wall's second state of the onion speech mentions exactly these three terms as the "virtues of community." I'm not sure how that ties in to what I'm saying here, but it probably does.