The level of scepticism surrounding software development estimates must rank with statements such as “the check’s in the mail,” and “You won’t find it cheaper anywhere else.”
It’s not like I’ve personally done anything to improve the reputation of developers’ estimating skills.
I’ve submitted a few howlers, and then paid the price by having to work nights and weekends to meet the ridiculous deadline I’d created for myself.
(Although the prize goes to my former boss – an incredibly intelligent and knowledgeable man – who estimated three days for what turned out to be six weeks of work).
…he estimated three days for what turned out to be six weeks of work.
So, why does it take programmers so long to get stuff done?
As I’m sure you’ve experienced, what gets us are the ‘unknown unknowns’: it’s impossible to predict everything that needs doing, without actually doing it.
But what if there was a way to speed up our understanding of the ‘unknown unknown’?
In this article I’ll be discussing some techniques for reducing the amount of time required for:
Kent Beck made everyone’s head hurt in 1999 when he published Extreme Programming Explained: Embrace Change. One of the outlandish ideas in this book was for two programmers to sit at one computer and do ‘Pair Programming’ together.
Results? One study reports a 15% increase in development time, but a massive reduction in defects. Also, the resulting code tends to be 20% shorter: a good sign for quality and maintainability.
Even though the development time is slightly longer, defect reduction is an incredible payoff – fixing defects is the most expensive and complicated way to get code right. Overall it took less time to get a functioning product out the door.
Now why would two programmers with one computer produce better results than two programmers with two computers?
Great question! But why stop at two?
Woody “No Estimates” Zuill went one step further and put half a dozen people in front of a giant screen, one computer, and called it ‘mob programming’.
Here’s a video showing a typical ‘mob programming’ day:
If you ever have an opportunity to see Mr Zuill speak, I highly recommend it. I saw him at YOW! Australia 2016, and was deeply impressed by his very human approach to dealing with teams as they solve complex problems.
Once again, teams working in this way have experienced marked improvements in code quality, both in terms of the code written, and in defect reduction. They also seem to get through more work.
One of the very interesting mob programming practices is that the ‘driver’ – i.e. the person typing on the keyboard does not participate in problem solving.
That’s super weird.
You’ve got a bunch of very expensive programmers sitting around and not using a computer, and the one person with a computer can’t provide any input on the problem at hand. They just type what they’re told (this role is rotated every 15 minutes or so).
This is because other team members must say out loud what they believe the problem is, what the solution should be, and how it should be implemented in code.
This results in reasoning and solutions being communicated with incredible clarity.
A super important upshot of this is that there is an extreme level of shared knowledge.
It becomes immediately apparent if a user story is not well understood by the team, if they need more information from domain experts, and everyone knows how and why solutions work.
This, for me, is starting to clearly illustrate what it is that holds up programmers. It’s obviously not typing speed.
Another incredible experience from YOW! 2016 was attending an ‘EventStorming’ workshop, hosted by the excellent Paul Rayner. This is to system design what mob programming is to coding.
Using a recount of a business problem and a maelstrom of sticky notes, teams can use EventStorming (that’s the accepted spelling, *eyeroll*) to develop a complete and shared understanding of problems and solutions in a way that creates a physical artefact (all those sticky notes) that can be scrutinised, recorded and modified in an intuitive way.
A bunch of sticky notes doesn’t sound very innovative. But let me tell you, I’ve never seen a bunch of nerds get so excited before.
Suddenly, here right in front of them, was a business problem laid out in a complete way, in a form that once again created a shared understanding among the team.
Rather than a solo designer (usually a business analyst) running around talking to people and working up a design, often in isolation, here we had a group of people developing and validating an understanding, and eventually a solution, that everyone agreed upon.
Once again, how does this relate back to what it is that makes programming work so hard to predict?
The man who formulated ‘EventStorming’ has a theory.
In his Leanpub book ‘Introducing EventStorming’ (unfinished – it’s Leanpub, right?) Alberto Brandolini suggests that it’s learning that holds up programmers. EventStorming is his solution.
I’ve often had the feeling that I finally, deeply and truly understand a problem domain…on the day the software’s released.
Have you experienced that?
Learning as the main bottleneck for programmer productivity is as good an explanation as I’ve ever heard.
Most of our time as professional programmers is spent working out what the problem is, and what solutions solve the problem.
You know how it goes:
We try one thing – doesn’t work…So try something else…Maybe that works better, but not great…Hmm that solves what we thought the problem was, but it doesn’t work like the users want…Reframe the problem and try again…
Eventually we get there.
Once we’re “there” we’ve learnt what works and what doesn’t.
Calling this learning is another way of describing a programmer’s job.
But this is what’s really interesting:
When we do this kind of work, doing it in a group provides an immediate opportunity for inspection and adaption of ideas and suggestions.
That sounds familiar, right? Inspection and adaptation are what agile practices are built upon.
Those who’ve been around the block a couple times will have run into the Mythical Man Month by Fred Brooks.
This is a collection of essays on software development where Brooks gives us his most enduring insight, in the form of a law:
Adding manpower to a late software project makes it later.
(That was back in 1975, so please forgive the gender-specificity).
Anyway, Brooks observed that throwing more programmers at a problem requires a lot of upfront learning (there’s learning again) to get the new people up to speed, and it also increases communication dramatically.
Eventually this adds up to a late project becoming even later.
But I don’t believe that this invalidates the idea of groups of people collaborating on a task normally done by one person.
I’m now a strong believer in the synergetic effect of having a group of people working on a problem at the same time. This is because working in a group radically reduces the amount of time spent learning about the problem domain by individuals in the team.
And isn’t that what teamwork is supposed to be about? Creating a whole that’s greater than the sum of the parts? If this wasn’t true, we’d never form teams in the first place.
It’s curious that the practices I’ve described in this article seem so counter-intuitive.
I think this is because we’ve become conditioned to think of “work” as someone hunched over a computer, typing furiously. A lot of the work that developers do doesn’t really need a computer – it just requires understanding.