Software Estimates and How to Make Them
By Spencer Hoffman
When it comes to making software estimates, there are a few things you’ll want to understand first. In this post, we’ll go over some ways to make estimates, understand where they come from, and how they (usually) work in the land of software development. Let’s start with some things that often remain unspoken, but shouldn’t:
- Some people do not want estimates. They want unrealistic promises for purposes that have less to do with the project, and more to do with making themselves look good in the short-term (for a promotion, bonus, whatever.) If you’re in this situation, you need to go out-of-band with your communication about the project (i.e., above someone’s head.) If it’s a client, you might consider talking to another stakeholder, or even to that stakeholder’s boss. This is a delicate act, and needs to be done with great care. In the worst case, you may need to refuse the project, as it may be getting set up to fail. If you’re the one actually building the system, you may find a new position/manager. This is just not a good place to be. If you are client stakeholder, this is a good time to step in and reassess your request (and who exactly is making it – i.e., is this the right person to be asking for the estimate?) Is the request reasonable? Does the research into competitive offerings need to be looked at again? Maybe the person asking for the estimate has made a mistake, or has motives that are not in line with the project’s goals. It’s also possible you’re dealing with a company that simply cannot handle the request you’re making. If you feel that this might the case, ask a few of their competitors for an estimate – you might be dealing with something out of the company’s league. This comes with a caveat, though – if the estimates given by the competitors (in light of your newly acquired knowledge) seem too good to be true now, they probably are.
When you’re asked for when it will be “done”, keep in mind that qualification of what “done” means is needed. Very often you may be asked for “calendar time”, not “perfect engineering days” or their equivalent. Make sure you figure out which one of these is actually being asked of you. If you’re the one asking for the estimate, be sure to specify which one you mean! Keeping this consistent will help the project immensely. If you want calendar time, ask for that. If you want engineering time, integration time, testing time – ask for that. Specificity will always be your friend on software projects. Vagueness is always an enemy.
Some estimates are well within the range of the possible, others are truly just not easy to come by. Figuring out the difference between these and communicating them is extremely important. Here’s a hypothetical conversation:
Client: “Build a perfect X system for our Foobarbazio engine.”
Custom Software Company (CSC): “GiantCo spends millions a year on this problem and still hasn’t solved it. No one has. More basic research is needed (on AI, ML, NLP, whatever) to even begin to do this. I’m sorry about that, but the state of the art is just isn’t quite there yet for what you’re asking”
Client: “I don’t believe you! Bilk-us Consultants says they can build it in 3 months! We’ll just go to them!”
These two types of estimate requests aren’t so easy to tell apart. If you are giving the estimate, do your best to politely illuminate the problems with the request. If you’re asking for the estimate and get answers like the above, talk through it and see if you can get to a request that’s more inline with what’s possible. If you don’t get anywhere, again, try a competitor. Multiple bids can may you better understand your own requirements.
That all said, there are many good rules of thumb to get you at least a basic estimate:
- Ask someone who has done it already. If someone hasn’t done the (almost) exact thing, ask someone who has done something roughly similar. If you can’t find that, ask someone who has done something /vaguely/ similar. Try to transpose the specifics (they used Oracle, we’re using Postgres; they used a great library, we have to write our own.) If this is truly green-field stuff, try to:
Build a prototype (If you’re the one building the system, that is.) No, you will not get the one million tiny details that can bite you during real development, nor the unknown unknowns that can crop up while trying to solve truly hard(er) problems, but it can be a helpful way for getting your mind wrapped around the problem. If this isn’t enough, you can also:
Build another prototype (it’s the second, so maybe we should call it a deuterotype.) Flesh it out. Make it bigger than the original, but ignore the (currently) irrelevant details. Yes, this takes longer, but it’s better than getting halfway through full-time development and realizing it’s not going to work.
If after doing the above, you feel like you’re no closer to an estimate, either give up and just develop it or have it developed, and you’ll eventually get to the point where you might be able to estimate the rest. This can of course blow up if you hit an impassable snag; that’s why it’s a last resort. If you’re the one paying, consider this a paid experiment; you might even be able to negotiate a special rate (and attach a contingent payout if the project goes ahead.)
Hopefully this will get you started in making and understanding estimates in the world of software development. It’s something you’ll be dealing with both as a client and a custom software company on every project you work on, so getting depth-of-understanding of this often nebulous art will likely greatly benefit you.
Spencer Hoffman runs The Gilded Ox. The Gilded Ox helps connect people, brands, and organizations that need custom software development; custom mobile app development; digital and offline ad campaigns; and marketing with the companies that provide them. You can read more from Spencer on his blog.