Better software development: the human factor, or how often are you interrupted?

Developer conferences are a great way to re-energise yourself and your work with new ideas, partly thanks to the content from the front, and partly because you get to engage with other developers. Technology changes constantly; but if I reflect on events I have attended I notice some common themes. Occasionally there are compelling technical insights - I think of the first time I heard Ryan Dahl describe the thinking behind Node.js, for example - but more often the most acclaimed talks are not about technology as such. Rather, they are about how we work together: communication, and simple truths about human nature.

This proved the case again at the Monki Gras recently, an unusual London event run by analysts Redmonk.

Craig Kersteins and Matt Thompson from Heroku asked a question: how often are you interrupted at work? Software development is partly about keeping a lot of information in your head so that you can see patterns and make connections, and avoid bugs by remembering exactly how the code you are working on fits into the application. Getting a summons to a meeting or a call from a colleague in the midst of that kind of concentration is costly. They even put a figure on it. 76% of the worst-performing engineers are frequently interrupted, they said.

How often is frequent? That was not stated; but they did suggest aiming for 4 hours of uninterrupted work each day. That still leaves plenty of time for meetings; and I have little doubt that 4 hours of good work counts for more than 8 hours of choppy work that leaves you feeling that you should not have bothered to turn up.

More human factors: Mazz Mosley and Nick Stenning from the UK Government Digital Service advised us not to recruit "rock star" developers who become a single point of failure, as everything stops if they become unavailable. A team with collective intelligence is better.

Ted Nyman from GitHub weighed into managers. They do not have any. I was reminded of a comment from Joyent's Bryan Cantrill at Monki Gras 2012: "it is very hard for middle management to add value".

Do I think that most companies remove all their managers? That is neither realistic nor likely to succeed. As another attendee observed, companies with managers generate a lot of revenue.

The point though is this: the way developers are managed impacts their productivity. That human factor matters more than whether they use Java or C#, or which tools they use.

I hear similar insights from the QCon conference in London each year. Coming up in March and recommended.

Shanley Kane from Basho spoke about honesty in software development. Roadmaps are a lie, she claims, because attempts to map features to a timeline will always fail. When roadmaps fail that erodes trust in the team. Interactive "what we're working on" documents work better, she said.

I will leave the last word to Cyndi Mitchell from Logscape and Thoughtworks, who remarked at Monki Gras that "Software is fundamentally a human, interactive activity. If you don't understand that, forget it."