Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!tut.cis.ohio-state.edu!karl
From: karl@tut.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.software-eng
Subject: Re: A Cynic's Guide, part 1
Message-ID: <7982@tut.cis.ohio-state.edu>
Date: 9 Mar 88 04:05:36 GMT
References: <2541@Shasta.STANFORD.EDU> <3584@bloom-beacon.MIT.EDU>
Distribution: na
Organization: OSU
Lines: 70
In-reply-to: tada@athena.mit.edu's message of 9 Mar 88 03:23:44 GMT

tada@athena.mit.edu writes:
   In other words, the software people are under more pressure to get
   their product out fast.  [yeah, i know -- all the hardware people
   who've ever had a deadline are going to flame me...]

This is related to the abysmal management styles that seem to go with
software management.  "If it's not perfect, that's OK, we'll fix it in
release 2.  Just get us on the market *first*."  The investment to
repair faulty hardware already in the field is positively monstrous;
the investment to repair faulty software in the field is (perceived to
be) small.

Example: At a department where I used to work (I won't even tell you
which job, so those of you who might know where I've been the last 10
years can't even guess well), a certain large product was arranged to
be delivered by a certain date.  This offense was committed by a group
responsible for setting up contracts but who knew absolutely nothing
of software engineering; this was evidenced by the ridiculous time
schedule they imposed on the developer-grunt staff.

First result, the original schedule was simply impossible to meet.  It
was hopeless from the outset.  There was no way to succeed.  Talk
about lowered morale.  Common bitch session over lunch: "How are we
going to deliver by MM/DD/YY?"  "We aren't, of course."  Be still, my
wretching stomach.

Second, there was no way to expand the schedule.  The contract which
both corporate parties had signed required the supplied date, period.
Delay was dealt with in the form of charges against my company as
$N/day where N is very, very large.

Third, management within the department was (ahem) suboptimal, in that
the already-excessively-tight schedule was arbitrarily tightened even
more by the department manager for reasons I don't even care to guess.
The initial beta-test delivery date was backed up 2 months.  Schedule
compression was required, which not only caused the loss of 2 months
of work before that delivery, but also 2 more days of work during
which the schedule tightening was performed by the entire development
staff.  You know the scenario: OK, everybody, pull out those schedules
that show your work done by MM/DD/YY, and find a way to compress it to
MM-2/DD/YY.

Ick.

Would this be tolerated in a hardware development environment?  Not in
any with which I have been associated.  As an example, if my group is
working on the next generation of 680x0, and we screw up the design
such that race conditions in the CPU are created, and we don't catch
the flaw until after we've shipped a couple hundred thousand of them,
our collective butt would be in a sling for sure.  The cost to the
company to replace the defective units in the field would be
absolutely horrendous.  Jobs would be lost for certain.

In software, though, the view is that it can be fixed for the next
release.  It's "just software," just park a new tape on the drive and
load in new binaries.  See, your bug is gone now.  Oh, you found
another bug?  Gee, we're sorry, that'll be fixed in release 3...

Bad management is the curse of software development.  Think about the
rather neat, high-quality software that is produced by people who are
not concerned with schedules much; my experience has been that such
software is far more bug-free than anything written under pressure.
This is especially true of real software professionals who are working
on something for themselves in their spare time that happens to be
useful to a larger group, so they start distributing it.

You know, come to think of it, my story about compressed schedules
fits *2* of my previous jobs altogether too well...

Karl