From: Bob Stout 

On Fri, 30 Apr 2004, Bruce D. Wedding wrote:

> 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?

As someone quite familiar with Jon's work (and also his habits, so I know
he's probably asleep by now and won't reply to this until tomorrow), I can
say that the programs he works on vary in size. Jon gets done on time
because he's quite good at scheduling, and he refuses to be browbeaten into
signing off on an unrealistic schedule.

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

Why write code which the customer doesn't understand? Write a spec in plain
English and have the customer sign off on 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.

That's why there are (or at least used to be) software managers - to fight
those battles with the marketing people. In your sort of environment, the
best you can hope for is to leave a good paper trail so that you have the
option of saying "I told you so" at some future date.

Jon and I have both worked in the world of clueless PHB's dictating fantasy
schedules. We approached it in different ways. I fought the good fight -
with about 50/50 results so far over the duration of my career. Jon
hunkered down and kept his mouth shut which made him infinitely more
popular. He worked from the premise that when the schedule slipped, where
he wanted to be was in a low visibility position. In addition to our
different temperaments, I rarely had that option since I was closer to the
front lines.

A few years back, Scott Adams wrote a book called "The Dilbert
Principle". As you might expect, it was a framework to hang some of
his better cartoons on, but it had one bit of amazing insight. He said that
current management trends began after the publication of "The Peter
Principle". For those not familiar with it, the Peter Principle says
that in any hierarchy, people are promoted to their level of incompetence.
The obvious corollary is that in any such organization, every position will
eventually become filled by people incompetent to do the job. This was a
wake up call to the business schools, whose solution was to churn out
scores of new MBA's so that companies would be managed by professional
managers. The fallacy that Scott Adams pointed out is that in a Peter
organization, you knew that every manager was, at some time in his life,
competent to do something related to the business. In today's typical
corporate MBA clubs, there's no assurance that *anyone* in the organization
was ever competent to do anything!

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

Although Jon is currently contracting, the environment in which he
currently works is very much that of a corporate programmer.

> I recall presenting a schedule to a project manager that had every
> resource working 24 hours a day to meet the due date.  My intention was
> to show him that the goal was impossible.  His pointy headed boss answer
> was to "reduce some of the task estimates!"

BTDT! Never do this again. The PHB's of the world will always react the
same way. When push comes to shove, make sure you have a paper trail
telling TPTB that what they've promised is impossible. It may or may not
make any difference, but it's there anyway.

-------------------------------------------------------------
Consulting: http://www.MicroFirm.biz/ Web graphics development:
http://Image-Magicians.com/ Software archives:
http://snippets.snippets.org/
  c.snippets.org/   cpp.snippets.org/      java.snippets.org/
  d.snippets.org/   python.snippets.org/   perl.snippets.org/
  dos.snippets.org/ embedded.snippets.org/ apps.snippets.org/
Audio and loudspeaker design:
  http://LDSG.snippets.org/   http://www.diyspeakers.net/

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