The futility of humility

There’s been a lot of chatter within my network about the pursuit, and virtue of, humility. Usually framed as ‘humility vs arrogance’

I don’t find the term ‘humility’ especially helpful. It’s an abstract concept and, as such, very subjective. I think that a majority of the disagreements that have occurred are based in part on a lack of agreement about the definition of the term.

Humility is, in many religions and cultures, espoused as a virtue, something to aspire to. It can also be used in a negative way, to denigrate or (hah) humiliate someone who might be perceived as a threat to an authority figure. The ‘know your place’ (i.e. subordinate to me) put-down.

Googling for ‘humility’ gave me the following quote from

The word humility signifies lowliness or submissiveness an it is derived from the Latin humilitas or, as St. Thomas says, from humus, i.e. the earth which is beneath us. As applied to persons and things it means that which is abject, ignoble, or of poor condition, as we ordinarily say, not worth much. Thus we say that a man is of humble birth or that a house is a humble dwelling. As restricted to persons, humility is understood also in the sense of afflictions or miseries, which may be inflicted by external agents, as when a man humiliates another by causing him pain or suffering. It is in this sense that others may bring about humiliations and subject us to them. Humility in a higher and ethical sense is that by which a man has a modest estimate of his own worth, and submits himself to others. According to this meaning no man can humiliate another, but only himself, and this he can do properly only when aided by Divine grace. We are treating here of humility in this sense, that is, of the virtue of humility.

Even in this single paragraph we have humility defined as being submissive, ignoble, of poor condition, not worth much, afflicted, miserable, being subject to pain and suffering. Who’d aspire to that??

Later on it talks about humility in a ‘higher sense’ as being modest and voluntarily submitting oneself to others. This is an improvement but still not something I really agree with. (The submitting oneself to others part is of course really useful if you’re a religious leader who wants to keep the flock docile). Make it a virtue to be aspired to and they’ll do it to themselves, yay!

But let’s assume a more modern definition: wikipedia defines humility thus:

Humility (adjectival form: humble) is the quality of being modest and respectful. Humility, in various interpretations, is widely seen as a virtue in many religious and philosophical traditions, being connected with notions of egolessness.

Being modest and respectful. Now we’re getting closer. Except… hmm, modest AND respectful. This is possibly why I take issue with the assertion that humility is a virtue (and, therefore, universally to be aspired to). Respectfulness I can totally get behind. I refute the notion that I must also be modest. In fact, if I tweet about how I’m seeking humility and why you should too, I’m really not being that modest, am I? So I’m not humble.

But I do strive to be respectful.

Now moving on to arrogance, which has been often mentioned as the only alternative option. Ie. you’re either humble or arrogant. There are no alternatives. And humility is good, so arrogance must be bad, right?

I’m running out of time to drill into it but my main dispute here is I don’t subscribe to the notion that arrogance is the inverse of humility, nor that they are context-free. I might be ‘humble’ when discussing hypnotherapy with my teacher, I’ve got about 20 days experience compared with his 15 years, it makes sense to be modest in that context. In the subject of software development I am definitely not humble. I also try to avoid being arrogant, but I am confident.

And I still strive to be respectful.

Enterprise Deployment

Every organisation I’ve developed software for held the belief that their deployment situation was special, unique and complicated. Most of them came up with convoluted release processes involving multiple manual steps, hundreds of configuration variables, shell scripts and workarounds.

The problem is primarily one of mindset. The presence of multiple applications at multiple versions and multiple environments on multiple machines can lead to a belief that it’s necessary to explicitly manage all of these axes as part of the deployment process.

I prefer a different metaphor: I always try to work as if the deployment artifact will be burned onto DVD and shipped all over the world. Treating software as a product like this makes it much easier to identify what is really part of the software and what must be configured as part of the installation process.

All of the environment/machine/etc specific information can be collapsed into configuration, eg. as a property file or command-line argument. Artificially separating them out leads to more complexity not less. It’s either part of the software (on the DVD) or it’s configuration. That’s it.

If I ruled the world

My next Java project would…

  • Be built with gradle
  • Use git for SCM
  • Check in deployable artifacts
  • Be an executable jar
  • Use JPA annotations for persistence

Would not…

  • Use maven
  • Use spring

Lessons from memory

Every now and then I take a stroll down memory lane and read some old blog posts, both mine and colleagues’.

After I stop cringing at how naive and earnest we all were I try and contrast my current opinions with those of my younger self and his young friends.

Some thoughts from tonight’s history lesson:

  • Be aware of your biases, preconceptions and beliefs. Consider how they might colour your interpretation of events.
  • Throwing away an acceptance test suite representing ten person-years of work because you want to use a different test tool is almost always a shockingly irresponsible thing to do.
  • A major high street bank based in Poole could have had an award-winning business banking website if they hadn’t (ostensibly) cancelled the project because it was going to deliver 3 months late. That was 5 years ago. It’s still not finished.
  • Technical excellence is meaningless without effective governance.
  • High performing teams are messy, loud, exhausting, chaotic fun and will still be discussed fondly whenever 3 or more members get together, even 5 years later.

The future is noded

The future is noded.

NOsql, Dynamic, Event driven, Distributed.

A tipping point has been reached. The JVM is past its peak. Dynamic languages with a low cost of change and greater expressive power are in the ascendance. Scaling through multithreading has been eclipsed by non-blocking single-threaded, multi-process architectures. Centralised databases are being out-evolved by distributed, eventually-consistent, semi-structured storage. Commodity hardware and designing failure-tolerance into the fabric of the system are winning out over specialised, high-cost solutions.

I’m seeing a lot of innovation in this area. It feels to me a lot like the ajax explosion. Before the term was coined, there were a lot of us ‘doing ajax’ without realising what it was we’d got our hands on, or just how amazing it could be. The XMLHttpRequest object was relegated to the back of the O’Reilly Javascript book and the most comprehensive documentation was a single page on Apple’s website. Once Jesse James Garett gave it a name, ajax was suddenly everywhere.

Thus: noded. A noded system is, generally: built on commodity hardware, horizontally scalable, fault-tolerant, (usually) in a dynamic language and operates at a scale far larger than any traditional solution.

So who has a noded architecture? Among others, Google (Bigtable, MapReduce etc…), Facebook (Cassandra), Twitter (FlockDb, Gizzard), Amazon (Dynamo). You may have heard of them.

A number of impressive open-source projects have been released by these organisations and others, and more have been inspired by them: Hadoop, Riak, MongoDB, CouchDB to name a few.

The platform that has me most exited at the moment is node. Javascript is a hugely expressive language (even more so with tools such as CoffeeScript) and node is rapidly accumulating an impressive collection of libraries that make building highly efficient, ultra-scalable applications incredibly easy. It’s not a coincidence that I like the term noded. I’d also settle for ‘nodular’ but Charles claimed that one in 2003.

Cheeky monkeys

It was when the backup file for my old blog reached 650 megs that I discovered that some naughty rascals had managed to store a bunch of mp3s on my server. Kudos to them for not buggering anything up so I didn’t notice until now.

The almost annual blog migration

Finding myself once again spending the christmas-new year limbo period mucking about with a year’s worth of backlogged blog administration and semi-traditional experimentation with alternative hosting. I wouldn’t mind except it’s almost impossible to avoid reading stuff I wrote 8 years ago and cringeing. I think I knew more then than I did now. Or perhaps was just more enthusastic about broadcasting it.