Possible attack; opinions wanted

[gaf at blu.org (Jerry Feldman)]

Drew, 
You are absolutely correct, but the exercise is called pissing into the 
wind. 
Years ago at Raytheon Data Systems, my manager convinced training to 
contract with Control Data to teach a course in Program Project Management. 
All the software management people took the course, myself included. All of 
us not only took the course, but believed in it. But, when it came down to 
implementation, it did not work. 
I've done a large amount of contracting at Digital/Compaq and HP. Most of 
the software management people buy into the planning. But when it comes 
down to implementing, the schedules tend to get compressed. Both small and 
large companies get cought up in delivery dates. In a complex project 
(software or hardware) there tend to be delays. We try to plan delays into 
the projects, but we also need to consider deliveries. 

However, there were several projects (mostly Digital) that were delivered 
on schedule. I worked on the Alpha Assembler for Windows NT. The existing 
assembler was encumbered. The plan was for 3 people (plus one part time 
tech writer) to complete the project in 3 months- Design, Code, Unit Test, 
and Test. The functional spec was the existing assembler manual. A short 
way through the project one of the guys had to drop out of the project, and 
I was asked to take over. It was interesting that one of the guys (the guy 
who dropped out) worked in another facility. The original project leader 
wrote the internal design. Our goal was to deliver the assembler for 
inclusion on the Windows NT SDK, which we did on schedule. 

Another project (not at Digital) was a project to deliver an encryption key 
management system for a network of about 3000 notes with an external 
encryption box. Spec'd at 3 months with 4 people on the Unix side and 3 on 
the encryption box side.
1. The functional spec, written by my manager was worth less than used 
toilet paper. 
2. They had not even decided what flavor of Unix they were going to use at 
the start of the project. 
3. Out of the 4 Unix engineers hired, only one was an experience C 
progammer. A second had some better design experience, but was a bit weak. 
A third was a smart guy who was very weak in C, but who knew assembler, and 
could come up to speed. The 4th could not code, period. 
First, the manager sold the project as a 3 month project when he knew damn 
well it was a 6+. He also turned down some very competent programmers. One 
friend of mine was turned down because he lacked Unix Workstation 
experience. 
Initially, my office was a small closet which I shared with an obese 
hardware tech who could barely fit in the office. He spent most of his time 
in the lab. There was no way this project was going to be successful.   
On 18 Jul 2002 at 14:27, Drew Taylor wrote:

> Hear, hear Derek! The trick is convincing the managers that the upfront 
> design is worth it.
> 
> And the company you mentioned develops the software that runs the space 
> shuttle. I don't think anyone will disagree that this is one instance where 
> the "plan before coding" mentality is absolutely essential. :-)

--
Jerry Feldman <gaf at blu.org>
Associate Director
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9