The mice are driving the experiment

My next speech on. For this one I thought I'd try to give the audience a window into the wild and wacky world of software development, as I see it. And the view isn't that good...

A twig. It all started with a twig. Someone, a long time ago, prodded something, and noticed that it moved. Ever since then we have been poking away at things, and developing increasingly complex machines based on the results of our prodding. That jumbo jet that flies above can be seen as the apex of this twig technology.^[1]

But our world is changing.

Through the wonder of integrated circuits we are now building machines out of the dancing of electrons. There are no moving parts in these machines. We are entering a new age – the silicon age.

Software development stands at the very forefront of this new age.

But if we truly look at the world of software development I fear that it shows we are not doing very well in this new post twig era. There are many issues, but I believe that there are two primary issues causing most of the problems.

But to explain, first you have to understand software.

Software can be seen as machines of the mind. Machines that have been created from words. Small sets of words written down to form tiny languages. With those small languages we instruct the electrons, building at first simple machines. As these tiny languages have such limited vocabularies, we communicate the ideas behind our machines of the mind with others through abstractions and metaphors.

Then we iterate, adding new words to our existing languages, developing new languages, wrapping existing machines to extend their capabilities, building new machines, and so on. We build on our past successes, learning from our mistakes... Of course, with the new languages and new machines come new abstractions and metaphors.

And so the circle of software development goes.

The speed at which we software developers extend and change our machines, languages, abstractions and metaphors mean that half of what a software developer knows today will be obsolete in three years time. This then, is the first issue: the need for continuous learning.^[2]

Very few software companies have learning at their heart. So much so that Starbucks will spend more on training a barrista than the typical software company will spend on training a developer. ^[3] Software companies thus expect their employees to keep abreast of the rapidly changing world through after hours study, or they rely on new hires to bring in the new knowledge they require.

This makes the industry ageist.

Think about it. The more time you spend working on a current language or platform, the less time you have to study and learn the ones that will replace what you currently know. Especially if you have a family.

So the industry is also set against people with normal family lives.

Which makes the industry inherently sexist.

Any women who take time out to have children will find that the longer they leave their return to the industry the more out of touch they will be – and thus less likely to find work.

Google is one of the few companies that I know of that have developed a strategy to help their employees learn: they allow developers 20% of their paid time to work on things that aren't in their job descriptions. To try new things out, to experiment, to learn.^[4]

When I tried to discuss Google's approach with the head of software development at a local company he was outraged – exploding in white hot anger at the thought that his developers would spend one day a week not “working”.

The next issue is subtly related.

People have ideas, and those ideas are turned into theories. But in software, those theories are mostly never tested. If accepted, they simply become dogma, a truth that all are expected to follow, unquestioningly. Those who don't follow are ostracized and ridiculed.

As an example there is a deep seated belief that there is at least a 10 times difference between the productivity of 'good' and 'bad' developers. But the truth is that there are no really valid metrics to measure programmer productivity. People can't even agree on what makes a good or a bad developer. So if developer productivity can't be measured, how can the belief have any basis?

We need look no further than the job adverts for software developers to see these two problems exposed: Employers choose to drill down on technology skills, riddling job adverts with acronyms, seeking years of experience in specific languages, platforms and tools^[5] . The industry is looking for people it doesn't have to train - and applicants have to prove that they don't need the training. Nowadays even people with PhD's can expect to be asked to write a test to prove their competence when they apply for a post.

But here in Australia, for every hundred resume's received by a software company, only one person will be hired. In the United States that figure was two in a hundred.

This is in an industry that claims that that there is a shortage of developers.

Only one in a hundred applicants are accepted.

Isn't this really symptomatic of an industry that is picky beyond belief, doing its level best to only hire the “good” developers that require no further training?

I believe that these two issues expose us as the illogical beings that we really are. Struggling with unfounded beliefs and not able to deal with an the need for continuous learning in our workplaces.

Software development is the experimental frontier of the post twig era. In that experimental frontier I believe that that the mice are driving the experiment.

Footnotes

[1] Douglas Adams was the person who I first heard make this observation. Read the book: it is recommended!

[2] Can anyone say "Innovator's Dilemma"? Perhaps one of the reasons companies claim to look for people who go to user groups and write open source software is that subconsciously we recognize that passion does trump rational decision making?

[3] I believe that McDonald's might also spend more on training their burger flippers than a typical software company will spend on training its developers.

[4] Atlassian also do this: I think that their business focused way of directing this might be a a better way than Google's.

[5] Yes: the more acronyms, years and jargon I see in your job advert, the less I expect that you spend on training your developers. The best job advert for developers I have seen simply read "Wanted: Scala developer". I applied, but didn't make the cut as I was deemed "not to be a good fit for the company culture". I understood that to mean that I would be the only developer on the team with a wife and kids - I was too old :-(