[prog] State of software engineering profession

[Mary]

On Mon, Apr 14, 2003, Jimen Ching wrote:
> 1.  Keep the same group of people throughout the project's cycle.
> When people are moved in and out of a project, the goal and design
> loses focus.  This is never a good thing for a project.
> 
> 4.  Never schedule the entire project.  It will never work out anyway.
> Instead, identify major milestones, and schedule only to the next
> milestone.  Of course, you should know the alotted time for the
> project.  And, this may be obvious but, have a prioritized plan before
> coming up with a schedule.  How else can you develop a schedule?  ;-)
> 
> 4a.  Always give youself two weeks of slack when dealing with
> hardware.  Note, the slack should not include delivery of hardware.
> In other words, if you've scheduled a month for a driver for some
> hardware, starting from the PO to a working driver, add two weeks to
> that.
> 
> 4b.  Try to identify the highest risk hardware as soon as possible and
> set it in motion.  High risk hardware are defined as hardware that is
> new (to the market), or that you haven't worked with before.

I've quoted the above because I want to ask you a question about these.

The question is:

    Assuming you are not running your own company, how do you go about
    convincing management of these?

Another question is:

    Do you have any method of addressing the most frequently cited
    problems in my posts and Rboert's? These problems were:

      - completely unrealistic hard schedules set by management (and
        worse, often by contracts with the customer);

      - changing customer requirements; and

      - the tendency of management to undervalue any and all QA once the
        interface is pretty enough for their purposes.

-Mary