Re: systems programming versus application programming

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 07/20/04 

Date: Tue, 20 Jul 2004 15:20:10 GMT

Responding to Gagne...

Unfortunately, this is a Hot Button for me, you you will probably need a
comfortable position and a six-pack.

> Maybe software is *supposed* to have a 70% failure
> rate. Maybe it's more biological after all and a 70% infant mortality
> rate is suggestive that we should start more projects (lay more eggs) to
> insure the survival of a larger (greater in numbers) 30%.

<Flame ON>
IMO the core reason for that failure rate is that software developers do
an adequate job of writing software but they are lousy at software
development. They are too absorbed in the Cult of Creativity to do
their overall jobs correctly. It is very satisfying to the ego to
believe that what one does is entirely a creative process that is
subject to the whims of the Software Muse and that to be creative one
must be above bothersome distractions like project management and
process control.

The reality, though, is that such an attitude does an enormous
disservice both to the direct customers and the rest of the business
orgainization. Software Engineering is not so uniquely special that
developers should be absolved of accountability. It should not be
different than other forms of engineering in its ability to manage
resources, schedule, cost, and quality. Nor is software development any
more creative than other engineering activities, much as we would like
to think so.

IME technical failure (e.g., performance infeasibility, incorrect
implementation, poor reliability, etc.) accounts for only a small
fraction of that failure rate. Most of the failures lie in project
management (e.g., poor estimates, insufficient resources, unrealistic
schedules, etc.).

Non-technical Management unquestionably owns a significant piece of the
failure pie because the softwre development process itself is not well
understood. For example, it amazes me that a corporation will spend six
figures evaluating copy machines and training everyone to use them but
it won't spend the same amount of money for mentoring when the software
organization switches its entire A&D approach for designing software to
a new paradigm and places the entire business at risk in doing so.

However, the root cause of such Management incompetence is often
indirectly traceable to the software developers themselves. For one
thing software developers usually have no credibility with Management
because their track record is attrocious for bringing in projects on
time and on budget. So Management feels obligated to do their job for
them by pushing back on every schedule item. The result is that the
developers end up being brow-beaten into an unrealistic schedule.

The root problem, though, is really the militant resistance most
developers have to monitoring their own work. They get brow-beaten into
unrealistic schedules because they have no data to back up their
estimates. [Without data those estimates are ka-ka anyway because of
the ego factor -- "I know I'm good, so /I/ can do that in a week." Ever
wonder why it is so easy to get developers to work lots of overtime at
Crunch Time? It's because in their hearts they know they underestimated
originally and they would rather work overtime than admit that.]

In a less PC era IT was know as MIS (Management Information Systems).
The operative word there is 'information'. One can't properly manage
without good data. If software developers refuse to collect data, they
are doomed to repeat the project management disasters of the past. More
ironic, data is really their only talisman against the unrealistic
schedules that they constantly lament. Contrary to what developers
would like to believe, all managers are not cast in the mold of
Dilbert's PHM. If presented with reasonable data managers will not
ignore it.

<Aside 1>
Back in the '80s a style of management known as Management By Challenge
had a short life as a fad. Basically the Manager would look at the
proposed schedule and say, "That's fine. But my challenge to you is to
find a way to bring this schedule in by 10%". The idea was to keep
everyone on their toes because it was already well established that all
the slack time in schedule was always used. Of course it didn't take
long for people to figure out they they should pad the original schedule
by 10%. So the managers challenged 20%, leading eventually to a
situation where the schedule was utterly meaningless.

Fortunately that was a short-lived fad. Unfortunately it lives on in
another form. Most shops have multiple projects working in parallel.
Ever notice that the schedules may have some slack time off the critical
path but the developers' time is always 100% allocated? Anyone who
thinks that if a developer takes longer on some task than originally
estimated it can be made up by schedule slacks is deluding themselves.
That sort of thinking leads to the Musical Chairs mode of resource
allocation where developers are shifted from one project to another at
Crunch Time. Then the Project Manager bitches because the promised
resources for a project aren't available.
</Aside 1>

<Aside 2>
A few years ago my wife was a doc manager at a small startup. She and
the QA manager had their acts together pretty well and they could
estimate accurately and meet schedules. The developers, OTOH, couldn't
hit a schedule if their lives depended upon it for a variety of reasons
(some of which, like poor or changing requirements, were not their fault).

When a new project was initiated there was a day-long Scheduling Meeting
to review Marketing's proposed schedule. If Doc or QA said they
couldn't meet it the discussion immediately went to remedies like hiring
contractors, shifting the schedule, or removing features. Typically Doc
and QA took about 15 minutes each to resolve their schedule issues
because they had credibility with Management.

The rest of the day was devoted to dealing with Engineering's objections
to the schedule. Engineering would say, "We can't do this in that
time." Management would say, "Why not?" Alas, Engineering didn't have
an answer and got stuck with an unrealistic schedule. [QA and Doc did
have answers that they had to trot out in their first couple of
Scheduling Meetings, but once they had done that they had earned their
credibility for subsequent meetings.]
</Aside 2>

The reality is that software development /is/ manageable and there are
shops that do it successfully. I was fortunate to work in one. In a
decade of militant process improvement we went from 300% schedule
overuns to -5/+15% variance. From MTTF to system crash of 40 minutes to
an MTTF of 2.7 years (including hardware). And we did it while
maintaining productivity that was integer factors better industry data
for the same sort of software.

Better yet, we went from long strings of 80 hr Crunch Time weeks to
virtually no overtime at all. The result was that it was a good place
to work and the turnover rate was almost nonexistent. I retired after
20 years and when I left there were a couple of people who had been
there longer. Perhaps more insightful, I was the only one who had ever
worked for another company. So buying into the Cult of Creativity ego
trip not only does a disservice to those outside the development
environment, it does a long-term disservice to the developers themselves.

In addition, the Cult of Creativity is a luxury that the <US> industry
can no longer afford. Consumers are beginning to notice that the only
thing that breaks in their lives is software and they are less accepting
of that than they used to be. Soon reliability will be a competitive
advantage and today's 4-Sigma will no longer cut it. To achieve 5-Sigma
and above software development is going to have to become much more
process-oriented.

Similarly, we rant about offshore outsourcing and blame it on low wages
overseas. In reality that is largely a croc. Anyone who has managed a
project across multiple development groups in different locations will
testify that there are lots of hidden costs and risks. All the low
wages do is get the vendor in the door for a talk because in total cost
terms they are just competitive.

What really carries the day is that many of the offshore shops are
process-oriented and they can deliver quality software on time and on
budget. If the in-house crew could do the same thing there wouldn't be
a problem. So it's time for developers to stop writing their
congressmen about trade quotas and do their jobs properly.

[Before the cards, letters, and death threats start to pour in about
outsourcing that didn't work, I don't deny that. My assertion is that
on balance it does work because it has been around since the '80s and it
has grown at an increasing rate. That couldn't be sustained without the
successes exceeding the failures by a large margin. IOW, I assert that
margin correlates with the different ratios of process-oriented shops to
Cult of Creativity shops.]
<Flame OFF>

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH

Loading