Calculating development time

Express the business side of your digital lives. Share your experiences and/or your comments regarding a business or organization.

No advertising.

Moderator: General Moderators

Post Reply
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Calculating development time

Post by Benjamin »

How do you do it?
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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)?
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

Yes, how does one predict how long a project will take to complete.
asgerhallas
Forum Commoner
Posts: 80
Joined: Tue Mar 14, 2006 11:11 am
Location: Århus, Denmark

Post 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...
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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...
(#10850)
martinig
Forum Newbie
Posts: 7
Joined: Tue Mar 21, 2006 6:23 am
Location: Switzerland

Post 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.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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..
Post Reply