Incompetence is the Most Powerful Force in Software Development

Incompetence is the most powerful force in software development. It's like dark matter. It makes up the vast majority of the observable software development universe but nobody has discovered how to harness its power - for either fun or profit. This doesn't stop people constantly trying.

In the many software development shops I admire, it is universally avoided. For example, at Atlassian, we concentrate on how to profit from software development using the best people we can find. I think we're resigned to the intractability of utilising incompetence.

For some, however, the allure of the ready availability of incompetence is too much to resist, and besides, it accumulates like lint or administratium. Only the good people leave. So why not harness the immense power of this abundant natural resource? Unfortunately incompetence is a force that can only be used for evil.

To a businessperson, incompetence is such an "obvious" business potential. It's tantamount to turning lead into gold. There is a desperation in business to believe that it can work and that there isn't some inherent value missing from that raw material. The rule applies for all skilled specialists, especially of newfangled, esoteric or otherwise incomprehensible arts.

In software development there's a long legacy of tools vendors preying on this desperation as they sell software that purports to make it possible for muppets to perform like competent professionals. No clue required. I have some future posts lined up on this topic, so stay tuned for some bile.

This post continues my apparent pattern of physics metaphors for software development:

The Laptop Law of Relativity
Quantum Mechanics and Unit Testing
When a Team Gels: a Motorcycle Powerband

So unless you've worked out how to turn lead into gold, avoid it or risk it all. Everyone knows, like a misconfigured hadron collider, incompetence can cause your project's universe to implode.

When A Team Gels: A Motorcycle Powerband

When a team gels, there's nothing like it. Explaining it does no use - it only sounds like a cliche or bad sports metaphor. But there's no mistaking the sensation you get. Not to mention the hyper productivity.

What it reminds me of most - me with my "overactive imagination" as Mr Ryan, my 4th grade teacher would say - ahem - what it reminds me of most is hitting the powerband on a motorcycle. Bear with me! I can bring this baby in to land.

Now this, I think I can explain. When you open up the throttle on a decent motorbike, the engine goes faster and obviously the bike accelerates. But (depending on lots of engine-type stuff) there can often be a point in the speed of the engine where several things come together at once, and you learn that once the revs reach a familiar resonance through the body of the bike, what was an ineffectual buzz only a moment ago transforms into a surge of forward force that teleports you down the road - wherever you point the thing - at a whole new category of fast. Instinctively you pull against this force as it threatens to rip your arms off and you become one with the machine, the front wheel unweighting and your face an immutable smile. It's like magic, but of course, it's just physics.

This gratuitous metaphor got me thinking about the "physics" of a team gelling and what factors contribute to it. Then I realised the metaphor goes even further.

In a team, the sensation of things starting to "gel" is a categorical transition. Team members anticipate each other's needs, they are able to judge the relative priority of each others goals and they can correct the natural misunderstandings that happen in all communication with greater speed and less fuss. The communication, the routines, the knowlege each member has of the others, it all starts working together.

I'm not going to put my amateur psychologist hat on (you know I've got one), but it struck me that this feature of the interactions between team members is very like a fluid dynamics scenario. It's complex and chaotic and all that, but under certain conditions, all the ins and outs and vortices and what not stop working against each other and find a kind of harmony.

Well guess what? That fluid dynamics scenario is literally what's happening in the engine as the motorcycle hits the power band. The timing of the fuel and air flowing into the engine, the combustion rates, temperature and pressure changes, exhaust speed, the lengths and volumes and shapes of each part of the whole breathing system work together more and against each other less.

So if you've never worked in a team that gelled (believe me you'll know if you have) then keep working towards it. Either that or get yourself a motorbike.

Brief, Incomplete, Wrong, Funny

Just spotted a pants-wettingly funny satirical history of computer programming languages over at James Iry's blog, One Div Zero, A Brief, Incomplete, and Mostly Wrong History of Programming Languages.

Here's a taste:

[Lisp] remains an influential language in "key algorithmic techniques such as recursion and condescension"

and

Lambdas are relegated to relative obscurity until Java makes them popular by not having them.

and it all started back in 1801:

1801 - Joseph Marie Jacquard uses punch cards to instruct a loom to weave "hello, world" into a tapestry. Redditers of the time are not impressed due to the lack of tail call recursion, concurrency, or proper capitalization.

Whereupon one wit proclaimed in the comments:

Jacquard's loom wasn't concurrent? It was pretty thoroughly multithreaded, I'd have thought!

Programming languages are furtile ground for satirical humour. Like the awesome Programming Language Designer or Serial Killer quiz and the ever growing mound of esoteric programming languages such as Brainfuck, Befunge and INTERCAL.