ColdFusion Muse

Why is Estimating So Dang Hard

Mark Kruger June 19, 2017 5:47 PM Business Of Development Comments (5)

Let's go Live to Bob and the Muse

Consider this typical interaction with a prospective customer:

  • Muse: Tell me what you need Bob.
  • Bob: I have an application hosted on ColdFusion 9. I want to upgrade to the latest version and move it to the cloud.
  • Muse: That's a good choice. The latest version of ColdFusion performs splendidly in the cloud and is much easier to manage. (yes the Muse uses words like "splendidly").
  • Bob: Great! How much will it cost me.
  • Muse: Well.... [lengthy pause]
  • Bob: Did I lose you? Muse... Hello...
  • Muse: Oh I'm here. I have some questions. What kind of application is it?
  • Bob: It's a customer portal where folks log in and use our whizzbang service.
  • Muse: Do you use any third party APIs?
  • Bob: Pbbbt... of course not.
  • Muse: Excellent - how about jar files. Do you remember using any jar files in your code to access Java stuff?
  • Bob: Jar files? What in the ham sandwich is a jar file?
  • Muse: It's a way you package Java classes. You might use it to do some complicated Java thing that ColdFusion can't handle on its own.
  • Bob: Uh... [Lengthy Pause]
  • Muse: Did I lose you? Bob... hello? Maybe we'll put a pin in that one.
  • Bob: Sorry my eyes just glazed over there for a second. Anyway, how much did you say?
  • Muse: Well I'm not sure I have enough information to uh...
  • Bob: Oh! and we also need to upgrade our thingy that posts reviews to Amazon and Yelp. Something about bees... apiary or something.
  • Muse: API Library maybe?
  • Bob: That's it!
  • Muse: [banging head on the desk] ok how about you walk me through the app.
  • Bob: Sure ... but... how much will it cost?

Now it's not the Muse's fault that he's having a hard time communicating. After all, if it was easy I'd be flipping burgers and still driving my '72 delta 88 from College. And before you get all up in Bob's grill, it's not his fault either. We IT natives tend to use lingo as if everyone has been exposed to the concept of an "API" or "java integration" or a "mouse".

So I'm going to let you in on a little secret. The bald truth is that development companies usually have no idea what something will cost even after you describe it to them thoroughly. The most accurate estimate for enhancements will always come from the original developer, and even then, they are often guessing wildly.

Muse Wisdom: Don't trust quick estimates or high levels of certainty!

Chances are if someone is throwing numbers around without asking a lot of questions and without being nervous about "guaranteeing" the cost, you are about to enter a relationship you will regret. Think Vegas chapel and too much bourbon and you'll get the idea. To help further the conversation about estimates I offer this 3-part blog series on "The hard task of estimating". My hope is that in the end, readers who are customers and readers who are developers will both come to understand a little more about this maddeningly ticklish task that we all must do.

Estimating is hard and estimates are often unreliable because of three main areas where issues arise:

  • Applications
  • Developers
  • Stakeholders or Customers
In this post we are going to talk about your application.

Read More
  • Share:

5 Comments

  • Phillip Senn's Gravatar
    Posted By
    Phillip Senn | 6/19/17 9:36 PM
    And how do you stop yourself from totally rewriting the application? If someone is upgrading, there code is more than likely outdated as well.
    When I was a child, I wrote as a child. I used tags as a child. But then came cfscript.
    Today, I use stored procedures exclusively.
  • Phillip Senn's Gravatar
    Posted By
    Phillip Senn | 6/19/17 9:37 PM
    their
  • John Bliss's Gravatar
    Posted By
    John Bliss | 6/20/17 4:20 AM
    Tangentially related:

    A trick I use is: these are the *only* estimates allowed:

    0.25 hr
    0.5 hr
    1 hr
    2 hrs
    4 hrs
    8 hrs
    16 hrs
    24 hrs
    40 hrs

    ...and, if >40 hrs, estimate is NOT valid without first breaking down the project/task into smaller parts and estimating each individually.
  • Mark Kruger's Gravatar
    Posted By
    Mark Kruger | 6/20/17 9:07 AM
    @Phil - Wait till my next post on developer problems. That's definitely one of them. ;)

    @john, Yes good tip! We are right there with you. Teamwise, we always break things into smaller tasks for estimating. Even 40 hours is probably too big for us - we would likely go back to the dev and ask for further breakdown. Even so, it's not what you estimate but what you miss - or sometimes just "how you think" that provide for pitfalls.
  • John Bliss's Gravatar
    Posted By
    John Bliss | 6/20/17 1:05 PM
    Right. I get weirded-out when I see someone estimate a task at, like, 38.25 hours or something like that. As tasks get long-ish, your ability to be *specific* about the estimate decreases.