The Divine Estimate

9/16/22

Projects can fail for many reasons and unreal expectations are high on that list.

At Buink, we measure our success by the success of our clients, which is why we’re always looking for clients who have a strong business plan, some business expertise, a good idea, and a good team. It is our job to deliver quality code that is bug free, intelligently written, and easy to maintain. It is our client’s job to be able to sell the project or features to customers or investors. When both of these jobs are accomplished, we’re all happy and we all WIN. When one job fails, then things get messy, and we work very hard to make sure it isn’t development that fails.

Our extensive experience in the industry and our ability to make development succeed is a source of pride for us. We’re experts at development, solving difficult technical problems, writing clean code, and delivering value.

That said, there is one part of our job where expert skill is very hard to attain: estimating.

When I started in this industry, I had no idea how important, and even vital, this very difficult skill would be. I had no idea how quickly my clients would assume we can do this easily, despite our lack of a reliable crystal ball. I had no idea how closely connected the success or failure of our work and reputation would be to this divine skill. Most of the time, this skill affects us negatively if we underestimate, but I also had no idea how easily we would loose potential work if we prophesy too many hours and too much cost.

Through time we’ve honed our skill, particularly with greenfield projects (projects that we build from the ground up). But even with existing projects, even sometimes projects that we built, things can get impossibly hard.

For example, the version of a coding language we use was recently depreciated and that forced us to upgrade several of our existing codebases (this is never a problem, by the way, for clients who sign up for a support agreement, but several don’t till a bug bites). We typically estimate an upgrade like this at about 12 hours. One project took less than half of that at a very happy 5 hours. The client was happy and we were a hero.

The upgrade on another project didn’t go so well. It triggered several bugs, which triggered issue with their IOS app, which required an upgrade to all front-end packages, which introduced other bugs, some of which were very difficult to solve. We were able to get the client back up and running, but not without a lot of unexpected work. The final time came in at a shockingly unsatisfying 50 hours. ALMOST 5X THE ESTIMATE! We worked closely with the client the entire time, but I can assure you, this wasn’t pleasant for anyone. You might think getting more work is good. Sure, we get more work, but it throws off our schedules, adds a lot of unneeded stress and pressure, and leaves the client unhappy.

The client who only had to pay for 5 hours of work was very pleased and we looked like a hero. The project that took 50 hours created all sorts of questions in the clients mind. Our skill level didn’t change between them. Neither did our expertise or our ability to estimate. Neither did the software choices we made. The only difference was the unique business logic and features of the project which become difficult to predict.

Here is the sad truth, ESTIMATES ARE ALWAYS WRONG! Even the project that took only 5 hours had an estimate that was drastically WRONG. Sure, it was wrong in a good way, but wrong nonetheless. I’ve never seen an estimate be exactly right. Never.

So, what is the solution? How can I keep all clients happy? The truth is, I can’t always keep all clients happy when part of my job requires the divine attribute of predicting the future.

Maybe I should always estimate the upgrade at 50 hours to make sure we never go over. But if we do that, there are no shortage of developers in the market place who will say anything to get the work. Then, if they land the project they’ll cut corners, ignore security best practices, forget to built the code in an easily maintainable way, and still probably go over estimates.

Do I estimate the update at 5 hours given that we were able to do one at that length? No, I don’t feel right about that either.

Instead, I try to give a number that will be closest to the average, which is 12. But again, 12 is wrong, except hopefully in a good way.

As you can see, estimates are an extremely hard problem to solve, and that is why I believe that the estimates are a wrong way to think about development work.

David Hansson, the creator of Ruby on Rails and co-founder of Basecamp, said the following in the article It’s not a promise, it’s a guess, “If you treat the estimate as a “best guess based on the limited information available to me before I start the work”, … you’ll change the frame and break the cycle of deadline anguish. Now the task becomes collaborative and you can share new discoveries with the stakeholders.”

Collaboration is the key here. If the developer is the right person, with the right skills, and the right dedication to the project, then estimates become an opportunity to communicate, not a breach of contract. At Buink, we rarely fail at delivering valuable code that meet business objectives, but if we do, it is usually related to an estimate being interpreted as a promise, not a best guess.

When we get in situations where expectations are increasingly unrealistic, I often feel like the developer in A letter from a technical founder to non-technical founders when he was trying to explain to his co-founders why the code was taking so long. He asks, “Have you ever started a project thinking that it is going to take an hour only to spend eight on it? This is just like that.” I think we’ve all had that happen and more so in development than any other type of task in my career.

Luckily, as we get more experience in the industry, we get better at predicting. We also get better at turning around projects if estimates turn out to be poor guesses. But, I’m quite sure we’ll never be perfect at it.

If you find yourself struggling to understand your engineering team, I’d highly recommend the book Shape up, written by Ryan Singer also of Basecamp. He says that we need to start thinking about development tasks in terms of appetite not estimates. Appetite is how valuable a given feature is to the business. When you combine appetite with priority, then you have a powerful framework to help product teams and developers stay on the same page, achieve business goals, and work together in harmony.

Here is a good summary video of Ryan’s book, Shaping in a Nutshell.

Hopefully, this information is useful to you as a non-technical founder trying to understand your technical team. If you’re ever in doubt about your technical team, we’d love to jump in and lend a hand. We can offer some valuable insights into how your team is running, how to improve their productivity, and how to know if things are moving in the right direction.

About The Author

Ben currently works as a senior developer and technical business consultant outside of Boulder, Colorado.

Read more about Ben

About Buink

Buink Web Development is a development shop founded in 2009 by Ben Buie. For years, Ben built and modified web assets for clients in Utah. In 2011, he moved the company to Colorado and in 2015 he started taking on new clients full-time.

Buink’s Core Values:

  • Cost effective technology (with business strategy in mind)
  • Eloquent, maintainable code
  • Responsive and transparent communication

Read more about Buink

Dru M.
Dru M.
15:41 25 Mar 21
Ben’s a super responsive, thoughtful, sharp and all around great guy to work with. Excellent with his trade. I’d recommend him to anyone. Thanks Ben!
Seth L.
Seth L.
21:36 29 Jun 19
Ben and team are incredible to work with. They are reliable and proficient. I'd highly recommend hiring them for web development work. SethVOLTAGE
Craig A.
Craig A.
20:50 18 Jun 19
It was a pleasure to work with Ben and his team. It is rare to find such attention to high standards of coding and devops.
Lexi S.
Lexi S.
15:36 18 Jun 19
Grateful to have Ben and his team as such a capable, reliable partner for completing client work!
Tom S.
Tom S.
13:18 14 Jun 19
I reached out to Buink after finding Ben’s name in a local developer/consultant listing in 2017, and I have to say, it has been an absolute pleasure to work with Buink. Ben consistently understands not just the development task laid in front of him but the business application behind the task. I’ve... never felt more comfortable with a development team than I do with Buink. I truly feel Ben and his team are integral partners in the success of my business.read more
Marilyn F.
Marilyn F.
22:47 13 May 19
I could not recommend Buink Web Development more highly. Ben and his team have recently developed a budgeting app for me (both web and IOS). I have had the opportunity of working with them for over a year and I am extremely happy with the results.I would say that the biggest plus for me is that I... trust Ben completely. From the very first, Ben has helped me make decisions that were in the best interest of my company. I have never felt like he is taking advantage of me. Ben does his best to keep the whole process very open and upfront. I have really appreciated that.I tell people all the time that I love my developers. And I do. I'm very happy that I chose to use Buink to develop my apps. It was the best business decision I could have made.If you are looking for someone to develop a website or app, I strongly suggest choosing Buink Web Development. They are fantastic!Marilyn Ference, President, Defend Your Money, LLCread more
James Landon B.
James Landon B.
01:33 28 Aug 18
Great company to help with all your web design needs!
Next Reviews
js_loader

Connect with Buink

Connect with Buink via email, send us a message, or subscribe to our blog.