[prog] State of software engineering profession
mary-linuxchix at puzzling.org
Wed Apr 16 10:00:03 EST 2003
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
> 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.
More information about the Programming