I messed-up: 4 lessons I learned about time estimates.

I am not someone who easily admits I’m wrong. Don’t get me wrong, I know I’m often wrong. I just don’t admit it. Especially when it comes to my area of expertise. So this post is particularly hard for me to do.

Inspired by the work of Brené Brown on vulnerability, I write this because never admitting you are wrong is just not healthy.

I also do this because there aren’t enough stories about mistakes and challenges that don’t have a fairytale ending. This blog post won’t end in me losing my job or my house. But it won’t end with me being rich or instantly successful either. It’s a blog post about how an experienced developer can goof up, and what I learned from it all.

Based on my research online and from talks with other developers, I know I am not alone. We just don’t talk about our mistakes much, unless there’s a huge pot of gold at the end to offset the “failure”.

The context

I recently worked with a client on a project that took 10 times longer than planned. You read right. Ten. Times. I really messed-up. Luckily, this client is great, and patient.

Things could have been much worst had we been on a tight schedule. But when we realized how poorly I had estimated this, we stopped talking deadlines: it would take the time it takes, period. Our focus became solely on producing the best possible app. He was very respectful and understanding.

And I had to stop bashing myself over the head and keep my cool. Now that it’s over, I went back and took stock of what went wrong.

What went wrong

It was a few different things, really. I underestimated the learning curve for a new framework I was going to use. I’m smart, and it looked so easy to work with. But there are always quirks and traps and gotchas. You can’t speed-up learning.

I also didn’t plan very well. I did prepare a document with time estimates, sure. But it was a case of false security. I wrote-up a plan so I could say I had done so, but really, all I wanted was to dive in and code. A lot of details were skipped because, in my minds eye, I could see they would not be a problem. Hindsight shows me how naïve I was.

I also skipped over a few things that are all part of normal project development. The overhead of meetings, email exchanges, research, etc.

Lessons learned

Lesson #1: Better planning

From now on, I’ll plan my apps through screen mockups, for a number of reasons:

  1. It’s much easier to communicate with my client.
    We are visual beings, and there’s no better way (even if your client is a technical person) to be on the same page than actually being on the same, physical, page and see how it will look and feel.
  2. It allows me to plan based on my own “time sinkholes”.
    I’m a great coder. Design, however, doesn’t come as naturally to me. That’s what takes me the more time to do. It also tends to be what I overlook the most when planning. By tackling the design first, it will allow me to think about all those details I tend to forget because it’s not my area of expertise. All the UI widgets I’ll need to create. What each screen will need to show, and do.
  3. It gives me a clearer picture of the needs.
    Designing the database structure, and building up the code will be that much easier once I know what will be needed on the front-end. The back-end stuff is what I have the most experience with, so it’ll just flow from the front-end specs.

Lesson #2: No more quotes

Time estimates are extremely hard to do.(see Estimations getting you down? Try planning poker for size) And quotes (i.e. guarantees it will take exactly that much time to do the job) are pretty much impossible.

So I will only provide estimates now, and in ranges. Because no two features are the same – even when they look similar on the surface. So I can learn from past work that task “X” takes between 1 and 2.5 hours. But your own version of task “X”, I have no idea how long it will actually take to build. It should be within that range, though.

And if it is not, then we will talk and see why it takes longer. Communication and trust are crucial to this relationship. So we’ll talk and figure it out. I also know part of the problem is my lack of experience with estimates. I will not forget it when we figure out how to move forward, I promise.

Lesson #3: Practice

Time estimates are a skill. So practice will make me improve. I will practice. Every day. I’ve even estimated how much time I think this blog post’s first draft will take me! (1h) So from now on, I will estimate every task I do in a day, and try to figure out where I over or under estimate, and why. And I’ll get there. (thanks for the tip Glenn Stovall!)

Lesson #4: Never – ever – compromise on quality

The last thing I take away from this is not so much about time estimates. It’s more about how to run my business in general. When the going gets rough, keep a cool head and focus on quality above everything else. You should always strive for this, of course, but in a case where you are going way off budget, it’s even more important. Transparency, communication and commitment are the only things that can make the best of this bad situation.

Conclusion

Goofing up that bad does not make me a bad developer. I am just not great with time estimates.

For a number of reasons, time estimates were not part of the job I did for the last 12-13 years. So that muscle is as flabby as Homer Simpson’s belly. Like any other skill, I need practice. And the mistakes I make while I train are teachers. They are not failures, they are learning experiences.

As one of my good friends tells me in times like this: chin up. Dust yourself off, pick yourself up, see what you could have done differently, and move forward.

So how was my estimate for this first draft? It took me 55 minutes. There’s hope for me yet.

UPDATE: I am reading Glenn Stovall’s wonderful Dependable book on how to improve the estimation process for freelance coders. I can not recommend it highly enough — get your copy today!