I really should get around to updating the theme on this thing.
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 http://www.newadvent.org/cathen/07543b.htm
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.
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.
My next software project would…
- Be written using node.js, Ømq, redis and riak.
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
- Use maven
- Use spring
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.
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.
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.