Everything Takes Longer

Everything takes longer than you think it will. Over time, you’ll get better at estimating, but when you’re starting out everything takes multiple times longer than you thought it would. The trouble is figuring out what that multiple is.

As a SW engineer with 10 years of programming experience and a masters degree worth of theoretical computer science under my belt, I can pick up the general ideas behind just about any web technology. What I’ve learned is that it’s the specifics that bite you in the ass.

For example, when I first saw the Yii framework, I thought, “Hey it’s PHP (a language I have a lot of experience with), it’s object oriented (my bread and butter), and much like Rails, it’s an MVC architecture that favors convention over configuration.” Every one of those concepts, I have experience in. “Piece of cake!”

Not quite. Every technology has little nuances that have to be navigated. Every day there’s something you didn’t plan for eating at your development time.

I don’t know whether it’s because I’m generally an optimistic person, or because I truly didn’t realize what I was getting into, or even that my excitement over the project led me to believe that I’d be able to accomplish magical things with respect to productivity, but I was off. Not just off, WAY off. Two to three times off!

There were so many little tasks along the way that I didn’t anticipate. And for the most part, they weren’t things I should’ve expected myself to anticipate. The thing is, you just don’t know. Every day is a gargantuan learning experience, and even having immersed myself in development for three months, I’m still learning every single day. In fact, a lot of those little lessons are so simple, yet so mind-blowing that I wonder how it is I called myself a developer (or entrepreneur) having not known them.

With all of those unknowns out there, how can I expect to ship on time? I estimate.

I take into account that I’m overly optimistic, and I take into account that unexpected problems will arise, and I take into account the fact that my initial estimates usually only include the minimum for getting something to work, not to put the required polish on the new feature before shipping it.

Your mileage may vary, but I look at each task and say to myself, “With 85% confidence, how many hours will this take?” and save that number in my head.

Now, if there’s anything in the process that I haven’t done before, if I have to learn a new API, or need to try a new jQuery technique, I take my estimate and triple it.* That’s my number. Even if it’s something I’ve done before and I can’t see any potential gotcha’s, then I still double it.

*If I have to do anything related to layout in IE, I square it

That’s my system, and from a project management perspective, I’d say my SPI is just over 1.2. That’s saying I’m overperforming my estimates. But again, that’s just a guess.

Going forward, I’ll be tracking my tasks more carefully so that I can track a more exact SPI value and adjust my estimating capabilities so that I come in on target. The goal isn’t necessarily to go faster (that’ll come on it’s own), the goal is to build my learning curve into my estimation so that I can hit deadlines and ship features as expected. It’s a bare-bones implementation of Evidence-Based Scheduling.

My lesson going forward is to track my productivity and use it to plan for the unexpected. There’s nothing worse than missing a deadline. You feel like a failure (and if you don’t, I’d argue you’re in the wrong business). You feel demoralized, and you’ve deprived yourself of the opportunity to build momentum with the “small win” of hitting a milestone. Don’t set yourself up for failure by being overly optimistic. Track it, and start being realistic.

Related posts:

1. Start From a Solid Base