Calculating development time
Moderator: General Moderators
Calculating development time
How do you do it?
-
asgerhallas
- Forum Commoner
- Posts: 80
- Joined: Tue Mar 14, 2006 11:11 am
- Location: Århus, Denmark
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
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.
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.
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.
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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...
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...
(#10850)
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.
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..
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..