Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

Tell me if this sounds familiar: 

Boss: "Hey man! So, it's time for our status meeting, huh? Okay. Let's get started."

You: "Well, we're working on the [deliverable] piece of [project]. We estimated it would take about 12 man-days."

Boss: "Uh-huh. How long have we been working on it?"

You: "About 8 man-days."

Boss: "And how much is left to do, do you think?"

You: "Probably 8 more man-days."

Boss: "What's the problem? Was there a hold-up, or a maintenance issue?"

You: "No. Once we got into [feature a], we saw some problems with the way it was implemented and we had to fix it to get the new stuff built. Also, when we estimated [feature b] we assumed the data was there, but it wasn't. [customer] also changed the requirements a bit regarding [feature c]."

Boss: "Okay, so you think we've got all the kinks worked out then?"

You: "As far as I can tell."

Boss: "So we're about 1/3 over budget. Can we safely say we'll be ready to test [deliverable] by [date 8 man-days from now]?"

You: "Barring anything huge, yeah."

If you've had that conversation more than twice, you've probably started adding 30% to your estimates, right? Twizardhat’s what getting better at software estimation is about, right? You estimate, and you track your estimates and the actual time it took and you begin to learn how long it takes you (and your team) to build software. After years of this, you can start to gauge the skill level of the team and the complexity of the project compared to other projects and teams you’ve worked on and you become adept at answering the “estimate” question.

We then rail on about “esti-quotes”. How a customer takes an estimate, that’s just a gut feeling based on your experience, and starts planning delivery dates and budgets around it as if it were a quote. When we miss estimate, we try and adjust for it next time, but with each new project, team and technology comes new variables added to our esti-quoting ability, and anxiety around software estimation continues. But, what’re you gonna do?

Stop Getting Better at Estimating

“Quoi?”, you might say, “What’s wrong with that?” I know I’ve spent a good portion of my career trying to get better at estimating. But what if I DO get better? How will that help the business? They’ll be able to better plan delivery dates and budgets. That’s a good thing. What else? Anything? That’s all I can think of.

Now what if I used my actual times to get better at building software? What if I took all the features (even the ones where I was over estimate) and tried to find ways to build each one faster without sacrificing quality? What if I focused on building higher quality software without sacrificing speed? How might THAT benefit the business?

Is It Good for the Company?

If I build higher quality software (loosely coupled and highly cohesive with all the “bilities”), how does that affect the company? First, it will probably better solve the business problem for which it was intended. There will likely be less bugs to fix (lower maintenance cost). It will take less time to implement new functionality (lower maintenance cost). When there are bugs, they will be easier to find and fix (lower maintenance cost). Adding or replacing team members is less costly, because the code is easier to understand (lower maintenance cost). It will take less staff to maintain it than more poorly written software (lower maintenance cost). Are you seeing a pattern here? Lower Total Cost of Ownership. Is that better than being able to plan delivery dates and budget better?

Get Better At Writing Software

kaizen This was the epiphany I had yesterday after talking with a friend of mine about our approach to Kanban at work. We were talking about “getting better at it”, but I was talking about getting better at estimating and he was talking about getting better at building software. We talked past each other for about 15 minutes before a light went on in my head when he said, “So you may get better at “guessing” when software will be done, but so what? I’d rather get better at building software.”

I almost broke my face smiling. “You’re right.” I said, “I don’t want to work at the fair guessing peoples’ weight.”

I felt a burden lift off of me. I HATED trying to get better at estimating. I always felt like there was no structure to it. There isn’t. I can have 90 years of software experience and still “guess” wrong when someone asks me how long it will take to build [feature/deliverable/project].

If I get better at writing software (something I LOVE to do), then I will get better at delivering higher quality code faster. Who cares if I’m 1/3 over my estimate if I’m cranking out high quality code in half the time I was six months ago? And if I can prove I’m getting better, I’m “guessing” that’ll be okay with my customer. :0)

Posted on Thursday, June 4, 2009 7:32 PM | Back to top

Comments on this post: Revelation About Lean Software and Estimation

# re: Revelation About Lean Software and Estimation
Requesting Gravatar...
Conveniently enough, if we get better at writing software, we can write code that's more flexible in dealing with those unexpected problems, reducing the size of our risks, and making estimates less likely to get blown out of the water. Otherwise, "getting better at estimates" probably just means arbitrarily tripling estimates, just in case...
Left by Anne Epstein on Jun 04, 2009 9:18 PM

# re: Revelation About Lean Software and Estimation
Requesting Gravatar...
Yes! Finally pointing out what I have been trying to say for years. We are inherently bad at estimating.
Left by Robz on Jun 07, 2009 11:03 AM

Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: