From: Jonathan Guthrie 

On Fri, Apr 30, 2004 at 12:39:30AM -0500, Bruce D. Wedding wrote:
> "I love deadlines, especially the sound they make as they go
swishing by."
> Douglas Adams

> JG >> "I complete roughly 75% of my major software projects
on time."

> That in itself is very impressive.  I'm guessing you write small programs?

Yeah.  The largest I've ever worked on is about 500,000 lines.  (It was a
modification of a source set of around 300,000 lines.)

The programs I'm working on now is around 15,000 lines.  The bulk of the
programs I worked on at Additech were around that size.  Of course, there
were something like 20 of them.  I prefer designing the system to have
mulitiple small applications to one giant program because the scheduling is
easier.

> JG>> Here's how to do it:  Start with a clear idea of what is to be
> delivered."

> 9 out of 10X, the customer doesn't have this so how will you get it?  In my
> experience,
> you get it by finding out what he doesn't want.  You get that by writing
> code and then
> having him object to how your wrote it so you rewrite it.

That is the least effective way of finding out what the customer wants. The
most effective way is to understand what the customer does.  Of course,
that looks like work, so nobody wants to do it.

> JG>> Next, add a sane schedule.  (An old engineer can tell you
how to create
> JG>> a sane schedule.

> God, I want to work in your world.  In my world, marketing and management
> create the schedule.
> Any input from engineering is promptly disregarded.

I keep finding jobs like this.  I don't know what's wrong with your world,
but I assure you it's on your end.  Where I come from, the schedule is the
result of negotiations between the guys who do the work and the guys who
set the feature set.  I used to think that Bob was the essential element in
all those jobs, but he's not associated with this one, so maybe not.

The main thing to do is to give a realistic estimate and to stick to your
guns.  The only time I've ever had scheduling trouble was when I let
someone tell me how long HE thought it would take.  Keep documentation so
that you can prove that you told them so when you say "I told you
so".

The other thing is, partition your feature set.  The only reliable way to
shorten a schedule is to reduce feature set.

> I think you have some good thoughts Jon.  Unfortunately, in the world of the
> corporate
> programmer and not a consultant bidding a job, we are not at liberty to do
> all that
> you suggest.

Wow, and here I though I'd had a collection of corporate programming jobs. 
My current employer (I just joined the 401(k) program) seems to think that
they've hired a corporate programmer.  Heck, we even sell office
productivity software.
--
Jonathan Guthrie (jguthrie{at}brokersys.com) Sto pro veritate

--- BBBS/LiI v4.01 Flag-5