Wednesday, 26 May 2010

An attempt at a simple, two-rule morality

I've been thinking about morality recently. Plenty of people claim to offer moral systems, but as a modern, relatively enlightened individual most of them seem to include relatively arbitrary injunctions, and as a geek most of them seem both over-complicated and over-specified, and yet still riddled with unhandled edge-cases.

Take the Ten Commandments, for example:

  1. I am the Lord your God
  2. You shall have no other gods before me/You shall not make for yourself an idol
  3. You shall not make wrongful use of the name of your God
  4. Remember the Sabbath and keep it holy
  5. Honor your father and mother
  6. You shall not murder
  7. You shall not commit adultery
  8. You shall not steal
  9. You shall not bear false witness against your neighbor
  10. You shall not covet your neighbour's wife/You shall not covet anything that belongs to your neighbour

As a modern weak atheist there seem to be some obvious errors or redundancies there:

  • The first two injunctions presuppose a belief in supernatural entity, so as someone who finds no rational reason to believe in a supernatural entity, these seem suspect or redundant. Firstly they could be better summarised as "Do not believe in any gods other than me". Secondly, unless God can himself demonstrate his moral authority (instead of, as most religions do, simply assuming it) they seem more concerned with promoting and propagating one religion than with laying down universal moral rules to live by.
  • The latter half of the Second Commandment seems to contradict the First Commandment and the first half of the Second. As a non-Christian, I would define an idol as an entity which is worshipped blindly and absolutely. This definitely includes the Christian God. Alternatively, one can take the assumed definition in context as "anything other than the Christian God"; but then (as above) it amounts to an empty re-iteration of the first commandment-and-a-half, which themselves rely on the undemonstrated assumption that the Christian God is an absolute moral authority.
  • The third again seems unnecessary - why should a system of morality define it as immoral to take the name of its creator in vain? A system of morality should stand up on its own to reasonable argument, and defining veneration of its creator as a moral requirement frankly sounds far too much like begging the question.
  • The fourth is simply redundant - why should a moral system concern itself with keeping a day of the week specifically marked out? Admittedly there may be some social benefits to setting aside a whole day of the week for adherents to remember and reflect upon their moral choices, but I don't see why such an injunction is morally good, rather than simply a good idea.
  • The fifth is again a good idea, but too over-simplified and prone to edge-cases. Sure honouring your parents is good for social stability, but what if your father is a deadbeat dad and your mother a shiftless crackhead? This commandment smacks entirely too much of the kind of unconditional, assumed authority that typifies the Ten Commandments, and is far too incomplete to serve as a good rule. Moreover, why should parents get special treatment? Why not simply honour anyone who is wiser, more intelligent or more experienced than you?
  • The sixth through ninth are pretty good, prohibiting murder, adultery, theft and lying. However, you have to be careful with definitions - for example, distinguishing between "murder" and "killing", which may include self-defence or defence of a third party). Moreover, I can't help wonder if these are overly specific, leaving out whole classes of immoral behaviour not explicitly prohibited. Take "dropping litter in public", for example - most of us would agree that it's a comparatively moral issue, and yet it's not covered by these four injunctions.
  • Leaving aside the implication that a wife is a possession to be owned, the tenth is again pretty good - I've always understood this as an injunction to try not to feel jealousy (because it's frequently a sterile, unproductive emotion), but rather to concentrate on bettering your own life and resist the temptation to waste it wishing you had someone else's.

Clearly, then, there's a lot of fat that could be cut, and a lot of edge-cases to handle.

Instead, I present my best stab at a moral system. It's only two injunctions:

  1. Do unto others as you would have them do unto you, at the highest level of abstraction possible.
  2. Always seek to minimise harm in the long run.

There are a couple of subtle but key points here.

"Do unto others as you would have them do unto you" is a pretty good moral system on its own, but the addition of "at the highest level of abstraction possible" removes edge-cases and makes it a lot more specific and defensible.

For example, it would now prohibit a masochist excusing undesired violence against others on the basis that he liked to receive violence himself. Rather, he is now constrained to consider their wishes when deciding whether it's acceptable to hurt others, rather than simply the shallow fact of his actions.

The second injunction is a somewhat Utilitarian attempt to minimise the total amount of harm in the world (where we define harm in the usual way, as "physical or mental damage").

This prohibits short-termism in decision-making (which often merely saves up problems or harm for later, possibly even increasing the total amount of harm).

It also allows for harm to be caused where necessary, but only where such harm is in the service of preventing greater harm - this would permit otherwise difficult moral choices, such as the hypothetical "killing a single child to prevent a nuclear weapon going off in a major city".

More trivially, it also permits things like "contradicting someone you believe is incorrect", but when considered in conjunction with the first, only if you're happy being contradicted or corrected by others in turn. It also effectively prohibits you from debating others' positions unless you're equally willing to give their arguments due consideration.

So that's it. The first injunction prohibits most non-victimless crimes, because we would all rather not be the victim of them, and the second permits harm to come to others, but only if we can reasonably assert that it will prevent greater harm elsewhere, or in the future.

With a little reasoning, as far as I can tell, every action or injunction we can reasonable justify as "moral" seems to be derived from these two principles.

Saturday, 15 May 2010

Geeks can be hard to work with

Geeks and especially programmers often have strong belief in "doing things right". People have remarked on this tendency, and given it a variety of negative characterisations: obsessive-compulsive, irrational, making a moral issue out of a pragmatic question.

As a geek and a programmer, I put my hands up to this stereotype - it doesn't affect us all, but enough of us (myself included) have some degree of it that I don't think it's inaccurate. However, I believe that far from being a drawback, it's arguably a vital component of a gifted developer.

I think this urge toward technical correctness comes from three main sources:

Obsessive-compulsiveness

Good programmers spend a lot of their time thinking in details - they have to, to be able to write reliable code. Programmers who gloss over or fudge details write buggy code with unhandled and unknown edge-cases.

Importantly, this code usually "sort-of" works most of the time (or at least, the obviously broken bits quickly get patched), and then occasionally fails spectacularly and catastrophically... at which point it's also usually blamed on the programmer who wrote it, rather than the manager who specified an over-complex requirement, or who provided an unreasonably small amount of resources (time, money, manpower) to achieve it.

Being a programmer is 50% artistic and 50% autistic, so it's hardly surprising that programmers can be a bit Aspergers-y about their code, especially when they're likely to carry the can for any catastrophic failures caused by it.

Artistic merit

Any programmer who isn't a journeyman or hack does the job because they like to create things, and as you get better mere creation isn't satisfying - instead you want to create things of beauty.

It's been noted before that (many or most good) programmers are makers - we need to feel that what we're creating reflects our abilities - something we'd be happy to put our name to - and we like delivering good, reliable, flexible, well-designed systems.

Banging out code or design you know is buggy, unreliable, inflexible or has unhandled edge-cases is simply not rewarding in the slightest. It's like hiring an artist to paint a wall blue, or hiring a sprinter to walk slowly to the shops for you.

To be fair, this is a very wishy-washy, non-business-oriented motivation, but I'd go so far as to say pretty much all the best programmers suffer from it - it seems to go with the territory, and not just from programmers, either - chefs are notoriously histrionic, artists are notoriously high-strung about their work and musicians are notoriously unstable or prone to mental illnesses. I don't think you can have excellence without pride in the work, and I don't think you can have pride in work without disillusionment and frustration when you're forced to churn out work you know is crap.

Pragmatism

I've been privately or professionally involved in software development for around 15 years. I've worked in a variety of companies, in a variety of languages and systems, and with a variety of different management styles.

Across all companies, management structures, languages, technologies and system there are only two things I'm utterly certain of:

  1. Given the choice between a longer/more expensive design and a simpler, less flexible one, management will almost always say "design it to the current requirements, because we'll never need <hypothetical scenario X>, and it would be a waste of time to build a system which takes it into account".
  2. From the date of hearing this, within six months to a year they will discover a pressing, immediate, unavoidable and business-critical need for scenario X... and if they don't react well to being told that this will now take longer to accommodate, they often react really badly to being gently informed this is the result of the decision they took several months previously, at which point you (or your predecessor) informed them that this would be the consequence if they ever encountered scenario X.

Personally I try very hard to avoid taking dogmatic positions on anything, but in the years I've spent programming (especially professionally, when you're most likely to have to compromise on the design or implementation to hit deadlines or budgets), I - literally, with no exaggeration - don't believe I've ever heard "we'll never need that" and then not had to implement it (whatever it was) within a few months of that date.

This only has to happen a few times (especially when you're responsible for cleaning up the mess) before you become firmly convinced that creating a system that's any less flexible than you can possibly manage is ultimately tantamount to just fucking yourself square in the ass.

There are reasons...

So yes - there are a number of reasons why programmers are obsessed with Doing The Right Thing, and why we tend to react with aesthetic revulsion to the idea of fudging designs, or hard-coding things for convenience.

Some of them are unfortunate but understood and accommodated in other disciplines - try commissioning an artist to produce art for your offices then ban him from using anything except potato-prints, or tell an architect (for deadline/budget reasons) to design you a building that they know damn well could fall down at any moment.

Others are actually vital aspects of being a programmer that you can't easily switch on and off - athletes have to be fit, programmers have to be anally-retentive and precise - and that you really wouldn't want to do without in your dev team.

Lastly, if you're a non-technical co-worker or manager, programmers often have a lot more experience working on software projects than you do, and have learned hard-won lessons you aren't even aware are available to learn... particularly lessons where they have to pick up the pieces from their own (or other people's) mistakes.

So yeah, geeks can be hard to work with. But then the guy who knows where the landmines are buried can be awfully prescriptive about where you put your feet as you navigate through a minefield, too. And unless you want your feet blown off, it's often worth listening to them.