Interesting article on the software development process

[David Kramer]

On Tue, 4 Jun 2002, Jerry Feldman wrote:

> He's got some good points, but some bad ones also. One point he makes is 
> "Only the programmer who is going to write the code can schedule it". From 
> years of experience as both a programmer and a manager, this is wrong for 
> several reasons:
> First, When planning a project, you may not yet have your team on board. 

That's true.  But if you don't know who is going to be doing what, you 
can't say how long it will take to do the work, either.  Different 
programmers have different strenghts and hangups.  You can't really come 
up with more than a ballpark figure.  

> Secondly, programmers are incurable optimists. A good software manager 
> knows how to take a programmer derived schedule and make it realistic. 

Abolutely.  I try very hard to be realistic with my numbers, and often 
come pretty close due to my experience, but I find myself being overly 
optimistic too on many occasions.  But having a manager take a programmers 
estimates and adjust it for reality and biases is a lot different than 
having the manager make up the timeline in the first place.  For one, the 
[good|experienced] programmer knows best what has to be done in finer 
detail, so even if he came up with the "to do list" and the manager put 
times on each item, it would still be an improvement over the manager 
standing up in front of the directors, spreading his cheeks apart and 
pulling numbers from between them without talking it over with the 
developers first.  When my boss gives me a complex assignment, I'm 
scribbling classes, methods, and attribute names while he's still talking.

> Thirdly, there are times when a schedule must be imposed. 
Absolutely.  And as with any multi-variable equasion, as one number is 
fixed, the other still need to balance out.  That means if the product 
needs to demo by the big trade show in two months (frustrating for the 
developers, but a valid business decision), and there's three month's work 
on the todo list, either more resources need to be added or more features 
need to end up on the cutting room floor.

I don't agree with everything he says; don't get me wrong.  But there are 
a lot of truths in there.  For instance, I have seen so many managers 
crack the whip or wave the carrot to get developers to work at 120%, and 
there is almost always one of three outcomes:
- The product finishes on-time, followed by several months of burnout and 
sub-par performance, so you pay for it with the next release
- The programmers work so fast that the bug list grows out of control, and 
the product is either shipped late or shipped buggy.  And managers will 
almost always choose to ship buggy and on-time over clean and late.  Or 
they cut the QA time down by 75%, with the same effects.
- The product finished on-time, then the developers stand around saying 
"OK, we put in our 120%, where's our reward?  And we don't mean pizza". 
Sure, the manager gets rewarded, but it never seems to trickle down.  Then 
you either have low morale or high turnover or both.


Bitter?  Oh, a tad.  ;)

Note: I am extremely happy at my new job.  I saw ALL of this at previous 
jobs though, and that was very frustrating for me.  I just finished my 
first more-than-a-coupla-days project at my new job, and came in two days 
earlier than my own estimate I gave my boss.  Win win.

-------------------------------------------------------------------
DDDD   David Kramer                   http://thekramers.net
DK KD  "The Hitchhiker's Guide to the Galaxy also mentions alcohol. 
DKK D  It says that the best drink in existance is the Pan Galactic
DK KD  Gargle Blaster."
DDDD             Douglas Adams, "Hitchhiker's Guide to the Galaxy".