TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
"S. Ron Oliver" <[log in to unmask]>
Fri, 2 Mar 2001 10:55:09 -0700
text/plain; charset="us-ascii"; format=flowed
"S. Ron Oliver" <[log in to unmask]>
text/plain (118 lines)
At 10:27 AM 2/23/01 -0800, C. Daniel Cooper wrote:

> > My story would go in a similar vain but the second team did get the
> > program built in one week and it did work 'OK' and it made management
> > very happy.  I was placed on the list for the next lay-offs and they
> > were promoted.
>I'm sure these stories abound. In my own equivalent, the other team's
>code was delivered to the customer in half the time, and I *was* laid
>off. Their code was "mostly working".

Well, in my "many" years of experience I have often been on projects with
"hot dog" programmers who swore by "quick and dirty".  Early on these were
assembly language hot dogs.  More recently they have been C language hot
dogs.  My experience with these "hot dogs" has been that they invariably
fail to deliver their fair share of the work on time.  And when they do
deliver, their work is invariably sucky.  Yet, management tends to be happy
with them.  My observation is that they are much better at convincing
management they do good work than they are at doing good work.

. . .

>But the point of my original email was not to elicit these stories
>(satisfying as they are); instead, it was an attempt at understanding
>the phenomenon. Why does "the other team" always seem to exist?

This is a key question that lead me, almost 10 years ago, to start studying
the whole "sucky software" issue.  It was very puzzling to me then.  I
still don't feel I fully understand the phenomenon, but I do understand it
a lot better than I did then.

"Hackers" thoroughly love being around computers and software.  They are in
this business because it is FUN, not because they have any particular
commitment to the profession.  To make matters worse, they have managed to
get into the business without receiving any significant education or
training to qualify them to be in the business.

One reason they are able to "impress" management is their deep love for
software.  Their enthusiasm is often mistaken for competence.  At the same
time, they are generally very intelligent - not r.e. software, so much, but
in general.  They use their intelligence to learn what buttons are most
successful with management, and work those buttons skillfully.

There are other aspects to this phenomenon, but I think these are 2 key
aspects of it.

>I wrote,
> > the developers either 1) don't see their software as being sucky --
> > a training/competence issue -- or 2) they tolerate suckiness in order
> > to meet deadlines, ie, they accept the development schedule along with
> > all the other requirements their product must meet.
>The common thread in our stories is that we reject the premise of #2:
>we refuse to accept a deadline that will induce sucky software. But
>the "other team" does accept it. Are their standards lower than

Yes.  Throughout (U.S.) industry there is little evidence that quality is a
serious consideration when it comes to "getting the job done".

>When I talk to these developers, I get a different perspective:
>they see themselves as "pragmatic", "getting the job done", "not a
>blue-sky academic", etc. Our view is that "suckiness is intolerable and
>the deadline is unrealistic;" their view is that "flawless software
>delivered late is sucky." They have made a tradeoff that to us is
>abhorrent: some degree of suckiness is tolerable versus missing the
>deadline; or more simply, some degree of suckiness is always tolerable.

Part of this is the jargon they have learned that "pleases
management".  Part of it is that they genuinely believe software can't be
implemented correctly in the first place.  If it can't be done right with a
LOT of effort, it might as well be done wrong with less effort.

>I really don't like arguing this point, but I think it's a reality
>that we in the Ada community tend to be blind to. We seem to think
>(hope) we can eradicate suckiness, via better tools and environments,
>better training and curricula, better processes and methods, and yes,
>by using Ada versus other languages. But if all these were in place,
>would suck-inducing deadlines go away? I think not; they would only
>get shorter :-(

Assuming that management gets proper training, I think deadlines would
almost become a non-issue eventually.  That is, both developers and
managers would focus more on steady, productive progress.  And, since far
less time (currently something like 80-90 % of developer time) would be
spent on maintenance, it would appear that projects are coming in ahead of
schedule most of the time.  But the detailed development of this argument
is quite lengthy . . . .

>Am I being overly pessimistic here? Is there some Utopia we can aim
>for, where sucky software is no longer built? Or, are we just being
>unrealistic in hoping so, since some degree of suckiness will always
>be tolerable no matter how things improve?

What we are talking about here is a substantial cultural change, after
which "suckiness" not only would not be tolerated, but would not even be an
option.  This, admittedly, is a BIG change.  But we have to start
somewhere. . .

. . .

S. Ron Oliver, semi-retired professor of Computer Science and Computer

caress Corporation is proud to be the U.S. representative for Top Graph'X,
developers of high quality software components, using Ada.  For more
information, check out

Tired of sucky software! ?  Check out and follow the
links to software sucks and The Oliver Academy.