Page 1 of 1

Calculating development time

Posted: Sat Mar 18, 2006 12:43 pm
by Benjamin
How do you do it?

Posted: Sat Mar 18, 2006 12:49 pm
by Roja
Note time, begin programming, stop programming, note second time. The difference between the two times is the development time.

Or did you mean how do we estimate how long something *will* take (future tense matters)?

Posted: Sat Mar 18, 2006 12:53 pm
by Benjamin
Yes, how does one predict how long a project will take to complete.

Posted: Sat Mar 18, 2006 1:06 pm
by asgerhallas
if you have calculated the development time the way Roja explained on some of your earlier projects, then take a look at them, find something similar to what you're about to do, note the time it took then, triple it and there you have the time i will take...

Posted: Sat Mar 18, 2006 1:08 pm
by feyd
Break the project down until it becomes tiny parts, maybe as far as individual functions to create/modify. Guess how long it would take you personally for each thing needed in optimum circumstances. Now add 150% (multiply by 2.5). You have your estimate. :)

That's the general path I take when estimating. After a while you get better and better at guessing how long something will really take. So it's mostly down to experience.

Posted: Sat Mar 18, 2006 1:27 pm
by Roja
Estimating relies on two things: Accurate records (to reference how long things take), and the ability to break a project into tasks.

Lets use a web page for an example.

You need a header, a footer, and content.

Lets say you've written an xhtml-compliant header before, and it took you an hour. It could take an hour to do it again, or you might be able to reuse that code. So we'll say 1 hour to be safe.

We've done the same with a footer, although it wasn't nearly as hard, so it only took 30 minutes. Again, we'll say "same as last time" to ensure safety.

Now we just need the content. If we've written a similar document, with a similar structure, then we can guess it will take a similar amount of time.

You get the idea, I hope.

Now, extrapolate that out to PHP applications and projects, and list common tasks:

- Build a webpage (output): Perhaps using a template system?
- CRUD (Create, Read, Update, and Delete) DB access: Perhaps a db abstraction layer?
- Security: Perhaps a unified input filter, and output escape system?

The list goes on. Now for each that you have done, it will either take less time (Because you know how to do it or you have code you can reuse), or it will take the same amount of time as the first time.

All that is left is to add up the parts, put in some reasonable padding for design and troubleshooting, and you should be fairly solid.

Posted: Sat Mar 18, 2006 3:17 pm
by Christopher
Accurate prediction require two main things: a clear specification of the work to be done and experience having done similar work. I am assuming that you will accept that your are as accurate as your experience will provide, but I don't see any mention of clear specifications. There are methodologies that help deal with this -- specifically these days would be Agile methodologies. One foundation ideas that Agile is based upon is that you actually know a lot less than you think you know, so you should plan less because you'll just be wrong. You may need some client buy-in to use these methodologies, but I find they can be presented with client friendly language so the client doesn't think they are doing any thing weird. I usually present it as a conservative, step-by-step approach, designed to save them money -- which I have found is pretty popular.

One thing that is hard for young know-it-all programmers to understand is that software development is pretty counter-intuitive. With these modern metholologies you have things like, Agile's resistence to a lot of designing and specification, or Test-Driven Developments completely backwards debug first - program second style, or its desire to replace traditional documentation and comments with tests. Those are pretty hard methodologies to use for programmers who have intuited themselves to their current development style.

I would suggest looking into something like SCRUM (here, here) and to reduce the amount you are trying to predict.

For example, say a client wants a new website that will have some data driven pages, rather than trying to figure everything out start with trying to predict how long it would take to just configure the webserver/database, install development libraries, and create the basic HTML/CSS layout. That would be a start. Create a spreadsheet with a column for your estimate and a column for you actuals (which should be pretty easy to track as they are small tasks). Then see how accurate you were. Maybe create an estimate/actual ratio from those numbers and apply it to the next phase of the project. Just keep at it...

Posted: Tue Mar 21, 2006 6:33 am
by martinig
Usually estimation is based on items identified during a first phase of project planning/general analysis. If you are using the UML method, you could for instance take the use cases as a basis for estimation (see for instance the article "Estimating With Use Case Points" by Mike Cohn, http://www.methodsandtools.com/archive/ ... .php?id=25). There are other methods/measures used to estimate the size of a system like function points or lines of code (LOC). The basic approach is often to estimate the "size" of the effort and then how you (or your team) can perform.

Posted: Tue Mar 21, 2006 11:38 am
by timvw
How much time do you spend generating use-cases? Are customers willing to pay for the "pre"-development phase?

I agree that it comes down to breaking the requirements down into blocks/modules which are easier to make an estimation for.. Counting them up and adding something between 1/2 and 1/4 as safety net usually works..