Re: How to calculate development time?

[Brovnik]

I won't try to answer all of the issues here, because it would take all day.
Your first problem is here.

I don't have the detailed spec yet, but need to know how to estimate a delivery time.

If you don't have a detailed spec, it will be difficult to estimate the delivery time.

Start by deciding how much work needs to go into producing the detailed spec.

You may want to agree that development as a set of milestones, e.g. :

1. Rough Specification
2. Detailed Specification
3. Initial Design
4. Detailed Design
5. Initial Development
6. Revise specifications
7. Final Development

You may only be able to give rough estimates for more than the first few, but you should be able to refine the estimates as you get further into the project.

Clearly you need to know the capabilities of the hosting platform so that you know what tools you will be able to use.
If you have to build some functionality from scrath, it will obviously take longer than if you can uise existing tools.

One way to get ideas is to find a list of existing sites and get the client to give you feedback as to whether they like some of the features, or how they would like it to be different. That can often give you a more concrete feel for the detailed requirements.

These are just a few thoughts. You really need to work up a detailed list of questions to make sure that when you start, your expectations about what you are going to deliver are the same as the client's.
--
Brovnik

[pmas]

From Murphy's laws for programming:
If something is easy, it'll take only twice as much as you thought.
If it is difficult, it'll take at least ten times as much. : )

No jokes now, project time estimate is a serious matter.

I agree with the steps above, and I offer useful 'trick':
Make customer aware that his/her thinking time also needs to be included, too.
I.e. "I'll need 2 weeks to develop Detailed Specifications *after you finished* reviewing and we agreed on Rough Specs."

Of course you will try to start 'Detailed Specs' right after finishing 'Rough', without waiting, but you need to won time… Like in chess game, to won you need to use your opponent’s time to think about your own next step.

Obviously if you thought you need about 2 weeks to do something and they wasted 10 days reading specifications and responding to your questions, you still need 2 weeks to finish the job, right?

Also, take into account you need some time in the evening to ‘recall’ where you finished last time. I call it ‘time for swap’. And like with disk swap, the more often you swap, the less time is available for a useful work. Looks like a lot of weekend work to me.

You may also ask questions:

• How complex is the project? Does it involve new skils? Do you want to learn these skills for free, or you do not care?
• Is it for the same employer you are working daytime? Same manager, same computer, or other? It might be bad.
• Do you have good relations with 'night project' customer? Afraid to stain them?
• Who will be available to answer to night project questions, and when?
• Who will decide quality of project completion? Penalty for missed deadline
• Is anybody else involved in the implementation? If yes, how much control do you have over other developers?

  I read a horror story about case when guy agreed to program in night something for his daytime company, was asked to take another guy to participate, then the other guy got behind schedule. To make for missing time he started sneaking into ‘night project’ during the day, and his day manager was not excited, because he wanted him to work overtime for day project, what was also behind schedule. As it happens, specifications were changed a little, he missed deadline a little, was required by his night manager to accept penalty…

  As a result, he left company with bad feelings with his day time colleagues and manager, and was not paid fair price.

  His advice: don’t do that, if you do not have full control.

  My advice: You’ve been warned. : )

  pmas

[Anonymous Monk]

I think this order of tasks is pretty good (especially because it "plans to throw one away") but incomplete. People (even technical managers) often completely omit testing time from project estimates. It is as if once the code is written the customer can deploy that afternoon.

I can see some naive justifications for this, but I have experience to the contrary:

Testing is done during development so it does not need to be scheduled.

Developers rarely test their own code this thoroughly, especially when they are on a deadline. Even when they do they inevitably miss something or other that's pretty serious.

Testing should not be scheduled because no one knows (or can know) how long it will take ahead of time.

That does not make testing instantaneous. Fred Brooks, author of The Mythical Man-Month (which is published in book form along with other essays of his; I strongly recommend the book) advises that a full one half of project timelines are typically spent on testing, whether testing time is scheduled or not. I have observed this myself to be a pretty good heuristic.

Another mistake people make is not having a test plan, or if they do, not scheduling test plan development! I have found that a test plan can be derived from a thorough design document fairly easily.

Testing should not be scheduled because the customer will get mad and possibly go with another bid.

The best of the three argumento IMO. Try to explain to the customer that testing is vital and that other vendors will spend just as much time on it; it's just that *you* are being up front and honest about it. If that doesn't work try not specifying a delivery date due to indeterminate testing time. Last resort, put an "I told you so" clause in the signoff document.

I've rambled too long. Don't forget testing time!!