Software estimates are hard. Clients expect things to take little time (see It Should Only Take You a Few Hours…) and cost little money. But the reality is that software is hard, there is lots to do, lots of work over and above just programming and it takes a lot more time and money to make good product. Most people underestimate the work to be done, or try to make the estimates look good, so most projects run over time and over budget because of this.

It’s bad for clients.

It’s bad for your reputation.

It’s bad for the industry at large.

You should estimate software as it is, because it’s always better to set the right expectations to your clients.

I just sent off an estimate for some iOS work to a potential client. But instead of estimating the work like it could be (and thereby misrepresenting the work involved), I estimated it like it is. In other words, I sent out a true project estimate, one that will probably not go over time or over budget, one that includes all the work involved, not just programming. But unfortunately, one that will not get me the work as the price is too high compared to the how it could be estimates they have received from others.

Let me throw out some numbers. The engagement is to create a simple flash card style game. I’ve done these before, and can whip a new one out in, lets say, 8 days pure programming time. From “Create Project” in Xcode to having the whole thing run from end to end, 8 days. Most software people would estimate 8 days times 8 hours times their hourly rate and be done with it.

That would be wrong. That is estimating software how it could be. How it could be if there was only programming involved, and all the art was done, and the product mechanics, experience and feel completely understood, tested, and worked out, all those involved had done several of the same kind of product before, and the program does not need testing as it works the first time.

How it could be is not real. It’s not even close. But unfortunately how most seem to send as estimates.

In reality, the product is not yet designed, the art not yet done, the client is new to creating software product, this is the first of their products to be developed, no code has yet been written for reuse, and no other product exists that works like it, feels like it, and has it’s same experience. In reality, there is a huge learning curve ahead for all.

When estimating how it is, at least the following additional work (and hence developer time) is required:

• Design the game scenes and game mechanics to match the nuances of this flash card game. This requires several meetings with the client, where you print out wireframes and play the game using paper cutouts to get a feel for the experience you desire.
• Create the placeholder assets and work with the graphic designer to create the real assets, in the right Slicy Photoshop format so that the developer spends less time generating and regenerating game assets. Include time to create the icon and iTunes store art as well as store text and screenshots. Include more time as artwork changes over the life of the development and more alpha releases need to be made and sent out.
• Double the development time because the first cut of the game with the first cut artwork never works, never feels right, it’s never fluid, the mechanics are wrong, and only by playing the earlier iterations of the product can you get a feel for where the polish and additional animations and interactions are needed, or where to try new ideas, all of which add time and effort.
• Add time for a proper beta test, sending the product out, answering questions, updating for bugs, and tuning for performance.
• Add time to finalize the game, install the final artwork, polish the final rough edges and get it ready for App Store release. And create the screencast and the web site and PR and generate buzz on Twitter and Facebook.

There is no way, under the how it could be estimate, that all these things can be done in 8 days of work as well as doing all the programming. Not going to happen. Not if you want a properly designed, polished, reliable, fast and good game, even though the mechanics are simple.

The how it is estimate for this game, excluding designer time, is really at least 24 days of work. That is how it is, at least three times the how it could be time estimate. Given past performance on similar products, we’re looking at close to the minimum right amount of time this can be made with an experienced crew (remember - it’s a simple flash card game).

You’ll note that I keep saying “at least” in the how it is estimate and all estimates are in terms of work and not duration. The art will take longer than you expect, and will require more iterations than you expect. The product will iterate through more versions and experiments more times before the mechanics, interaction and feel became “right” than you expect. Most of the time, you are learning what works for this product each time. And as you learn, things change.

So please, folks, when estimating software next time, take the time to add in all the peripheral stuff that increases work on the project like design and testing, take into account the learning experience, take experimentation and iteration into account, even take how the last project really went into account, and estimate software how it is.

You may not get the work. But at least you are not misrepresenting what will happen to client if they go with the wrong estimate, and you can sleep peacefully at night.

And when you do get the work, clients will remember that your estimates and your delivery were close, were real, and true. And that’s how you build a better reputation for yourself, which leads to more work, and more great products, and more delighted customers.