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 build, 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 website maintenance 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.
