The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Software scheduling

Hi all,

I am  a freelancer programmer, want to know that how to schedule a project.

I know various theoretical models, but I am not satisfied with them.

Please tell me that How to estimate time for a particular module. what are the key points behing successful scheduling.
AJAY PORWAL Send private email
Monday, November 28, 2005
 
 
Google "feature points"
Ed
Monday, November 28, 2005
 
 
Berislav Lopac Send private email
Tuesday, November 29, 2005
 
 
==>Google "feature points"

We called 'em "function points". Is there a difference?
Sgt.Sausage
Tuesday, November 29, 2005
 
 
Feature Point estimation augments Function Point estimation by including an accounting for algorithmic complexity, IIRC.  At least as I am familiar with the term.

Peter Coad's Feature Driven Design agile method might include some related complexity metric that goes under this name, though I'm not aware of it.
F.P.C.
Tuesday, November 29, 2005
 
 
If you're not satisfied with various scheduling techniques, you need to look at why you're not satisfied with them.

For example, I know a lot of developers who hate writing requirements, functional specifications or lists of features.  They prefer an iterative development model where they get the basics, "ship it", and then add successive layers based on feedback.  In that scenario, a monthly maintenance schedule is probably better (or whatever the "ship it" method prefers).

On the other hand, if you're continually failing to meet your estimated schedule, that's a completely different problem.
Anonymous Coward
Tuesday, November 29, 2005
 
 
Err...  I just realized my last sentence could be interpreted several different ways.

It's possible that your basis for your estimates is too low.  I.e., tasks you think should only take an hour, can't be done in less than four.

It's possible you don't have way of tracking slippage as it occurs.  For example, if you craft a status report every month, an hour's slippage every day builds up very quickly and by the month it's really hard to compenstate for that inertia.

It's possible you're thinking of only what the customer needs, not what you need.  For example, in addition to the actual coding time, you need to budget time for maintaining your billing records, scheduling and performing backups, buying and evaluating tools, etc etc.

Once you figure out exactly what the problem is, you'll have a much more useful scheduling process.
Anonymous Coward
Tuesday, November 29, 2005
 
 
Incidently, as a tip, never give the customer your most optimistic schedule.  :)
Anonymous Coward
Tuesday, November 29, 2005
 
 
Do what the smart sofwtare estimating people tell you to do. Then double it.
YaYaYa Send private email
Tuesday, November 29, 2005
 
 
In my experience, developers normally estimate the time to write the code and doing a minimal amount of white box testing (maybe it's only their lack of knowledge about a big picture)

Every added feature adds a new testing dimension which makes the testing time rise geometrically.

After that there's production deployment, where something always goes wrong despite each conceivable test.

After that there's the time required to go after the latest client's variation requests.

Last but not least, sicktime, holidays, management time, etc etc etc.

Defining a good schedule is more an art than a science
Sevenoaks Send private email
Wednesday, November 30, 2005
 
 
Damn fine question, OP!

Let me add another point to Anonymous Cowards list of problems:

It's possible you fail to identify all tasks during a design phase and discover them half way during coding.  I'm not an Agile Methodology weenie but I think XP plans for discovered features... (correct me if I'm wrong).
Paul Norrie Send private email
Wednesday, November 30, 2005
 
 
I'm developing a smaller scale tool at work, and I'm using Joel's painless Excell schedule for it. In addition to the basics described in Joel's article, I've added some VBA to compute the total time it will take to implemented all features (one per row) on the selected rows. If I select three rows, Excell will compute the total time for those three features, based on the "time spent" and the "current estimate" values in hours.

More specifically, I have an "hours per day" cell (set to 5, because that's the amount of effective work I can do per day), an "adjustment" cell set to 1.2 by which I multiply the estimated time. Then I compute the number of working days it will take me to complete the selected set of features. Finally, I have a function that computes an "ETA" based on weekdays and a list of holidays I keep in a array in the VBA code.

I also added a "Release" column, in which I enter the target release for a feature (say "1.2"). Once I've decided on the list of features for the next release, I sort my table by release, then I select the whole bunch and report the estimated ETA in another cell marked as "Objective".

Whenever I want to know how I look, I select the features that are left for the next release, and compare the estimated ETA with the objective ETA. Based on that, I shuffle my features around to meet the dead-line.

Finally : for each release, I have a feature called "Testing", which takes a good amount of time. The Debugging is included in the "Adjustment" ratio.

I've found that it works pretty well. So far I've been able to hold my dead-lines, skipping a few features along the way when needed. The point is : my managers are happy when I'm on time, because they know when I'm supposed to ship, not exactly *what* i'm supposed to ship (I keep my schedule private).
Carl Seleborg Send private email
Thursday, December 01, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz