> The "work" ethic I spoke of is not a code of standards and practices,
> but rather personal beliefs and principles that dictate the diligence
> with which an individual applies to their work to produce a quality
> product.

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.

Quality/suckiness exists within a context; this in turn constrains
the degree of acceptability. Development time and funding are part
of the recognized context, and so is time-to-market pressure; but
customer acceptance of suckiness is something we don't understand
(due to our bias).  Preceding emails anticipate looming disasters,
advocate liaisons with the legal community, propose certification
standards, seek to beef up curricula, etc. But what's the problem that
these are solutions to? Is suckiness per se a problem?  Or, should
we instead focus on ways of specifying "how sucky is ok" for this or
that context? Said that way, suckiness simply indicates missing

What is suckiness anyway? Can software that meets all its requirements
still be termed "sucky"? If so, is it the requirements that are sucky
and not the software? And if that's so, is it the customer's fault? In
another direction: is suckiness the repetition of mistakes we should
have learned to avoid? Is it overrunning a time/dollar budget? Is it
missing a market window? ie: is the development process sucky and not
the software? I think these are appropriate questions for this Ada
forum since they can help expose our biases. We all abhor suckiness,
but is that just a personal preference that predisposes us toward Ada
and blinds us toward the "real world"?


C. Daniel Cooper ==========v=======================.
Adv Computing Technologist | All opinions are mine |
206-655-3519               | and may not represent |
[log in to unmask]  | those of my employer. |
The question is not "What is the answer?"; rather, |
the question is "What is the question?" --Poincare |