When will you be home?

What time will you be home today? It’s a simple question. If you’re like most people you go to work and come home about the same time every day. You should be an expert in estimating when you’ll arrive at home. I bet you cannot predict the time that you’ll get home tonight, though. I bet you’d be even less accurate if I asked you to predict what time you’ll be home six months from now.

Sometimes I feel like this is what we ask software teams to do when we ask them for estimates. Software developers build software every day. We should be able to predict how long it will take to build new software – but we can’t reliably do it! There are ways to improve our estimates, though.

Let’s jump back to the commute example. If your commute is short then you’ll be accurate most of the time. Sometimes you’ll have a meeting that runs late. Maybe it’s Friday and your calendar is clear so you take off early. You can be way off from time to time, but pretty often you’ll be pretty darn accurate. This is why we want to break deliverables into small pieces. Small pieces have less uncertainty.

Things get less predictable the further out you go. Going from a half-mile commute to a mile commute will increase the variability. One mile to twenty miles increases that variability by orders of magnitude. There are simply more unknowns as the size of your commute grows. Traffic, accidents, weather – there are a lot of variables that can affect the actual time.

Big features and deliverables have this same problem. There are simply too many unknowns to be accurate. Undocumented limitations of libraries, complex algorithms, changing requirements, for example. And asking software developers to commit to anything with that level of variance isn’t fair.

But it’s done anyway and leads to all kinds of dysfunctions. Unrealistic estimates based on little knowledge are treated as promises. Broken promises lead to distrust. Distrust leads to infighting, incessant status reporting, and pissed off developers.

So lets stop asking for estimates that are months away. I don’t know even know what time I’ll be home tonight 🙂

Loss Aversion and Tech Debt

Humans are loss-adverse. We place an irrationally high value on losing something over gaining an identical item. So for example, I’d be more upset about losing $10 than the happiness I’d feel by gaining $10. If I buy a meal and hate it, I’ll likely finish it anyway. In general, people would rather gamble on […]

On Hiring Techies – Evaluate Potential, Not Accomplishments

This is a part of a series on Hiring Techies. Evaluate Potential, Not Accomplishments I don’t spend a ton of time reading resumes. Depending on the position we’re hiring for, I may look for a few critical skills but I’m mainly looking for themes that tell me that the candidate has a passion for technology. […]

On Hiring Techies – Hire For Cultural Fit

This is a part of a series on Hiring Techies. Hire For Cultural Fit I said it earlier, but it bears repeating: I can teach someone a new technology. I cannot teach someone how to fit into our culture. A lot of technical interviewers are laser focused on a candidate’s skill set. I’ve been asked […]

TDD: Back to Hand Rolled Stubs

I’m unashamedly an Agile practitioner and self-proclaimed enthusiast. It’s not a perfect way to build software, but I haven’t found anything better. And until I do, this is the approach I’m taking. Building Quality In One of the core principles of Agile is the focus of building quality in from the start, not asserting quality […]