TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: "Deller, Steve" <[log in to unmask]>
Date: Wed, 21 Feb 2001 21:11:49 -0800
Content-Type: text/plain
MIME-Version: 1.0
Reply-To: "Deller, Steve" <[log in to unmask]>
Parts/Attachments: text/plain (71 lines)
> -----Original Message-----
> From: C. Daniel Cooper [mailto:[log in to unmask]]
> Sent: Wednesday, February 21, 2001 2:01 PM
> To: [log in to unmask]
> Subject: sucky software (was: The Good and Bad News about Java)
>
> ..
> While I strongly agree with the comments about lack of
> professionalism,
> I think it's also fair to point out that, in my 33 years in industry,
> I have never known a developer who *wanted* to produce sucky software
> (although I have known many managers who did, consciously). Rather,
> 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.
>
> > Unfortunately, the real world (management) imposes
> > schedules and expectations that are less than realistic.
>
> I see this as the leading cause of sucky software; the professionalism
> issue, although extremely relevant, is unfortunately secondary. But
> why is the "real world" so unrealistic? (Wow, that sounds like an
> oxymoron!) I think a big part of the answer is something that
> we in the
> Ada community are quite blind to: suckiness is not binary,
> but comprises
> a spectrum of acceptability. (Ouch! It hurts to say that.) Instead,
> we don't see suckiness as something to quantify. We take quality as
> a given, presumed in every discussion. It is our bias. It's why we
> embrace Ada in the first place. We assume everyone should share this
> bias. But regrettably, I'm coming to see that quality may not be the
> absolute that we would like it to be.

When I was a few years into programming, and just starting a job at CSC, I
had the VP of the entire division come to me to write a piece of software.
He wanted it FAST.  I told him I could do it in two weeks.  He said he
needed it in one and told me to do it QUICK and DIRTY.  Now I am known to be
stubborn at times :-), and insisted I did not know HOW to make quick and
dirty software, only how to develop software correctly.  This led to a him
eventually ORDERING me (shouting at me) to do it QUICK and DIRTY.

I went off and came back to him when things had cooled off and told him the
program was done.  He wanted to see it.  It immediately failed, since in
reality is was the assembly equivalent of begin;null;end.  He immediately
demanded to know what the hell was that.  I told him that was DIRTY
software.  I asked him just HOW DIRTY did he want his software.

The upshot is that he left in a huff and gave the project to someone else
that promised it in a week.  Two weeks later, I had a proper working version
of the software, having worked on it on my own overtime.  I told you I was
stubborn.

I gave it to the VP.  He was happy to have the software, but was
understandably cool toward me.  However, it turns out the other group that
was working on the QUICK and DIRTY version was STILL debugging three weeks
later.

I have always been very proud of that interaction.  The only difference from
then to now is that I've learned to hold the same line without all the heat
and argument.

In subsequent experience, I have met managers that understand
schedule/quality/capability tradeoffs, managers that understand it and don't
want to recall it, and managers that don't understand it.  For the latter
two catagories, starting with begin;null;end can sometimes lead to a
reasonable dialog.

Regards,
Steve

ATOM RSS1 RSS2