Oh, it's not that hard

Scenario: We are sitting in a planning meeting and a business stakeholder asks one simple question. “How hard would that be?”

What answer do we give? The one I hear most often is “Oh... not that hard.”

“We’d like you to download every page on the internet and index according to how accurate the information is for a set of all possible keywords. How hard would that be?”

“Oh... not that hard. I can do it!”

“Great. We’ll see you next week!”

“How hard would that be?” It’s a legitimate question that every stakeholder is perfectly entitled to ask. Why then do we always answer it the same way?

When asked this question, I think that we as developers hear something altogether different. Instead of hearing the question “How hard would that be?”, we hear “How good are you?”

The implication in that question is that if we are good then the change being requested won’t be that hard. And we are of course, awesome, so the change is, of course, easy!

The fallacy here is that we focus on ourselves, not on the problem. We fail to consider the tests we’ll write or the state of the code base we’ll inherit or any of the other things that could possibly go wrong.

The result is that we end up setting up a false expectation that the change will be fast. This causes us to overcommit and then fail to meet that commitment because we spent so much time on “easy” changes.

What then is a better response? How about this: “Hmm... that change sounds like a very interesting and important one. Let’s create a story and then we’ll estimate it.”

In one simple step, we have validated the stakeholder’s idea, and we have taken the focus off of us, the developers. We have placed the focus back on to the work itself. Once the task has become separated from our person, we are free to estimate the work without trying to prove how awesome we are.

When we do this we help everyone involved. The stakeholder gets a more realistic picture of how long changes will take. We are able to deliver on our commitments without heroics. The code stays clean because we’ve given ourselves the time we need to make and test the change properly.

In the end, everyone will know how awesome we truly are when we deliver on time with exactly what we promised. This is one of the principles of craftsmen at 8th Light. We humbly and quietly demonstrate our skills with quality, on-time delivery. We do not inflate our abilities by pretending that everything is easy.

Doug Bradbury, Director of Software Services

Doug Bradbury is a maker, a thinker, a craftsman, and a learner.