Coding effort estimation

[serg3d]

Can anyone point me on some coding effort estimation tutorial for dummies (on the web please, I have no time waiting for book :( ) ? Especially for modifying existing code, not writing from scratch....

[princec]

Anything anyone tells you will be a complete red herring. I should know, it was once my job to do this precise activity.

The only reasonably consistent metric we could work out was to take a zip of the source code and compare the compression ratio with the raw source. The more it zips up, the simpler the source code is. This is universal in any language, and has the benefit that it is largely agnostic of whether the developers have used long identifiers or short ones.

Cas :)

[Dom]

I doubt there is such a thing.

It will vary so much on the programmers experience, the complexity of the task, whether it is modifying someone elses code (how well commented/written it is etc.) and so on.

[edit: Remembered something our business advisor used]
A slight improvement on the 'take what they say & double it' (which is often quite accurate):

Ask you programmer for an 'expected' figure.
Ask for a WORST case figure
And a BEST case figure.

Add all these up and divide by two, and you get an 'average' with a 50% contingency. Good for planning with, not so good for costing though!

[MrPhil]

Ask you programmer for an 'expected' figure.
Ask for a WORST case figure
And a BEST case figure.

Add all these up and divide by two, and you get an 'average' with a 50% contingency. Good for planning with, not so good for costing though!
Studies have shown that developers underestimate jobs on average by 30% so I use a formula like Dom's that takes that into account.

WORST case figure * 1.3 = definitely done date
BEST case figure * 1.3 = very optimistic done date that probably won’t happen

If you are trying to estimate a job you are going to do yourself, then I'd break the project down into function areas and estimate the time for each function, add them up, and increase by 30%.

That’s my approach. Looking for a more scientific approach? See Mithril Studios post: http://forums.indiegamer.com/showthread.php?t=856

I’d also add that if you are approaching something new, and don’t have a solid idea on how you are going to implement it trying to estimate the amount of work is impossible. I find it more useful to experiment with different approach’s without focusing on the time involved. If you put a deadline on research you usually won’t discover the best solution because you are too worried about finishing on time.

[Mithril Studios]

Unfortunately, I don't think there really is such a beast. Effort estimation has been, and continues to be, a large research area within Software Engineering. It's a non trivial task to come up with a system which produces consistent and accurate estimations. All of the systems I am familiar with take time to learn and become proficient with, and also require a good sized database of effort and productivity.

However, with that said, take a look at:

http://www.processimpact.com/articles/delphi.html

This gives an overview of using the Wideband Delphi estimating method, and it may give you enough information on actually conducting an estimation (I didn't read all of it.) It does require more than just you to come up with an estimate though.

I use the Personal Software Process, but I've got a 450 page text book on it, and took a semester long class on following the PSP - so it's not an overnight solution.

-edit
The previous couple of posts are good rules of thumb - but be sure to use them with the understanding that they are guesses and not backed by any statistical support - i.e. they could turn out horribly wrong.

Anthony

[Bluecat]

If you are trying to estimate a job you are going to do yourself, then I'd break the project down into function areas and estimate the time for each function, add them up, and increase by 30%.


That's a good way of doing it.

I've done a bit of study of Extreme Programming over the last few years. Unfortunately I've not worked anywhere where it has been practised, but I've still been able to use bits and pieces, especially in my own work at home.

The XPers recommend writing all of the functions (or stories, or use cases) out on cardboard cards first. I've used those index cards that you can buy from any stationery store, but in practice you can use anything as long as it's flexible. With these you can estimate velocity reasonably easily. You just need experience.

After you have written out as many stories/use cases/functions as you can think of, you lay out the cards and pick the first stories that will be implemented in the first iteration. If a story is too complex, break it into two or more smaller stories. After the first iteration, usually two weeks, you (or the team) works out how many stories have been completed and that is your velocity. After several iterations you have a pretty good idea of how fast you are working and if the number of stories doesn't change you can reasonably estimate how long you are going to take.

You can then apply this to your next project from the start, once you have worked out the details.

Now a couple of caveats.

This process works best when you are using a lot of the XP process, because the process as a whole emphasises quality. Test first programming, pair programming, and the other aspects of XP attempt to catch bugs and quality issues early on when the cost is lower. There is also an emphasis on having a customer controlled process. At the end of each iteration the customer tests the system and has the right to change his mind about any story. It might sound counter intuitive, but it allows the ability to have a rapid response to issues early on when they cost less. In game terms, if the customer asks for a feature that turns out to be not fun, it can be removed early instead of two days before completion.

Oh, and the biggest thing of all. Don't implement what you don't need for that story/iteration. Don't get ahead of yourself. This is hard. I still struggle with this one myself. It takes discipline.

I also don't know how this works with other game assets. I suspect similar methods could be employed for art and sound, but I'm not sure about that.

Hope this helps.

[Kai Backman]

Here is a nice article from Joel again:
http://www.joelonsoftware.com/articles/fog0000000245.html

I agree with him, it's not about getting it right, but about improving over time. I recently started using FogBugz just because it has a nice integrated way of doing these estimates. In practise the system is pretty similar to what I was using when running an XP project.

John, regarding eXtreme Programming you might be interested in reading my post mortem of Space Station Manager:
http://www.mistaril.com/about/post_mortem_ssm.php

Short conclusion (to spoil the suspension): IMHO it doesn't work for games. If you search google with for the postmortem title there is some heated discussion on a few XP lists .. :D

[Greg Squire]

I have to cost out projects in my day job. Only, If the project is similar to things I've done before, can I even come close to a good estimate (educated guess). When the territory is more unknown, then my estimates aren’t close at all (sometimes less; sometimes more). I try to make a conscious effort to pad (inflate a little) my estimates to give myself a “safety buffer”, however there are still times where a project goes over that. This is not science by any means, it’s purely guesswork.

[otaku]

Experience goes a long way to estimating task length. Experience also goes a long way to mis-estimating task length.

Two good book references that are quick to read:
Project Management Black Book
The Complete Idiot's Guide to Project Management

Personally I make use of Microsoft Project & FogBugz. I make use of a variety of techniques based on the situation, so Use Cases, Stories, task & to do lists. I've found that no one estimating technique works in all situations. Some rules of thumb: I've learnt that anybody that tells you to "take whatever the developer tells you and double it" can be safely ignored. When asked up front people will tell you what you want to hear, and when asked to break down tasks and put it all on paper for their own sakes they'll get closer to the truth. Any developer who gives you an estimate of longer than 2 hours without having worked through all the steps and estimated each one can also be safely ignored as having poor estimating skills. Ideal task length should be between 30 minutes and two hours. A "task" of less than 30 minutes is more of a to do item. Joel Spolsky states what I also believe to be true, the purpose of estimating is not to get it right but to improve your capability of estimating over time. An "estimate" is just that, it's not carved in stone. Better that you have a complete picture of everything you have to do with inaccurate times rather than really accurate times of only those things you are vaguely aware of. I would "estimate" that a project of any length (such as a casual puzzle game) when everything is "done" is around 2,000 tasks long. Our current project has around 1,200 tasks in our Microsoft Project schedule and several hundred TO DO items (things that take a minute or two). I expect to add several hundred more tasks before the project is "gold."

[Bluecat]

Thanks for the link Kai.

Your postmortem was an interesting read, and offered some good insights. Correct me if I'm wrong, but it seems to me that you believed that XP was a good choice for the lower level libraries (and engine?) but not so good for gameplay. It also fell down with non-programmable assets. That doesn't surprise me since graphics and sound don't strike me as being particularly suitable to develop in an iterative fashion.

Your PM also approved short iterations for development, but not post release. That's what I'd expect. In the context of the original question, did using short iterations and simple requirements help you with your schedule estimation?