Steve McConnell book, Software Engineering as a...blah blah

[John Ellsworth]

Well, someone wants to make software engineering into a true profession by
requiring sign-off licensing. As an ex-lawyer who now practices software
engineering as both a developer (MCP) and web architect, I can tell you that
the practice of law, as just one example, has certainly not been made more
professional or "better" by allowing only attorneys to sign off. Rather,
what this requirement has done, has taken the law away from the people, its
real owners. Anyone care to try round 2, and improve the practice of software
development by applying (once again) this same technique? McConnell, your
software engineering books are excellent (even we unlicensed engineers can
read, comprehend, and apply as required). May I respectfully suggest that
you stick with what you know, and leave the licensing arguments up to those
who would benefit most--the regulatory agencies and bureaucrats all too anxious
to jump on your bandwagon and so disempower yet another group of process
owners.

[Craig Clearman]

John,

>Anyone care to try round 2, and improve the practice of software
>development by applying (once again) this same technique? [licensing]

As long as Round 1 was creating the requirement for civil engineers,
I'd certainly expect to see benefits.

Yes, I know: "post hoc ergo propter hoc." Just because the practice of
civil engineering improved in the decades after licensing of civil
engineers became commonplace does not mean that the improvements were
caused by licensing. But the same argument is true for your example:
lawyers.

Overall, I enjoyed the book, but not as much as I enjoyed his previous
works. Before anybody buys _After the Gold Rush_, you should realize
that it is a manifesto, not a reasoned argument. For instance,
McConnell will bring up examples of disastrous software errors. Then
he will bring up data showing how defects decrease and productivity
increases when you use stronger methodologies. But he does not even
attempt tie the specific software failures to a failure to follow a
stringent methodology.

Ciao, Craig

[Thor Kornbrek]

IMO Anyone has the right to publish software. I do not think that Licensing
is the answer...I feel it will stifle innovation, and further reduce the
number of people that enter the field.

I think it is the consumer that is responsible for deciding what level of
expertise they require. Buyer Beware. Engineering does provide consistent
quality, but often is limmited in innovative capability by that same reliability
factor.

What I am saying is that Engineers should take advantage of all of the good
but poorly implemented ideas, and improve them. Professional Certification
Already Exists.

We need less government not more.
Thor

[Craig Clearman]

Thor,

>IMO Anyone has the right to publish software.

Nobody is suggesting otherwise.

Instead, McConnell is suggesting that an independent licensing bureau
should be created for software engineering. (Actually, he suggests
that it be folded into ABET). Then, a licensed engineer who is
willling to take personal responsibility for a piece of software can
sign off on the software. After he signs off, he is personally liable
for the software, and can be sued for malpractice if it turns out that
the software was not developed in accordance to recognized best
practices, and it fails.

The first thing that you'd see would be a small number of software
professionals get licensed, so that their consulting firms could be
awarded government contracts.

>I think it is the consumer that is responsible for deciding what level of
>expertise they require. Buyer Beware.

Exactly. But there is no independent measure of quality assurance
today. Instead, you tend to draw conclusions based upon the company
that produced the software. But that falls down often, as large
software companies have disparate levels of quality.

Ciao, Craig

[Chad Mello]

You sound so rational yet so stupid all at the same time! Right now, for
example, gun manufacturers can be sued for producing a firearm that actually
works to official, standard engineering specifications simply because it
was misused by another person! I gun is a relatively simple mechanism with
basically one intended use.

Imagine the Pandora’s box that would be opened by legally encouraging suites
against a responsible party for software with bugs! My God, man, you are
nuts to even THINK that would work! Software (even small programs) can get
VERY complex VERY quickly. The most complex cases in the history of the
judicial system would be derived from this. Imagine trying to prove or disprove
a bug that you are liable for. Now imagine trying to determine if you even
SHOULD be held liable for certain bugs. What if your bug actually came from
a third party component? What If the bug only occurred on certain hardware
or configurations? Was it an OS problem? How about a hardware driver problem?

You are Nuts, nuts, nuts, nuts …NUTS!

[Craig Clearman]

Chad,

>You sound so rational yet so stupid all at the same time!

Thanks, I try.

>... gun manufacturers can be sued

May I introduce you to off.ramp? You'll like it. Get a newsreader, and
point yourself there. Nice rhetoric, but you really aren't saying
anything useful, except for the following:

>What if your bug actually came from
>a third party component? What If the bug only occurred on certain hardware
>or configurations? Was it an OS problem? How about a hardware driver problem?

There is no difference between these issues and issues in civil
engineering. To your point: what if the building materials were
shoddy? Who would be held responsible?

It's simple. If you signed off an a project using materials (or
components) that were not certified by another engineer, you would be
held responsible. If another engineer had signed off on the
components, and the fault was with them, he would be responsible.

>You are Nuts, nuts, nuts, nuts …NUTS!

Don't mince words. What do you really think?

Ciao, Craig

[Mark Newman]

Craig Clearman <chclear@nospam.please> wrote in message
news:f8odgs4gj6992m62ck68dsjbe9e898gm8i@4ax.com...
> ...snip
>
> >What if your bug actually came from
> >a third party component? What If the bug only occurred on certain
hardware
> >or configurations? Was it an OS problem? How about a hardware driver
problem?
>
> There is no difference between these issues and issues in civil
> engineering. To your point: what if the building materials were
> shoddy? Who would be held responsible?
>
> It's simple. If you signed off an a project using materials (or
> components) that were not certified by another engineer, you would be
> held responsible. If another engineer had signed off on the
> components, and the fault was with them, he would be responsible.
>

I don't think that having an engineer "legally liable" would ever fly.
Underwriters Labs (or any of the others, such as CSA, FM, etc.) might test
and certify that a given electrical device meets all applicable codes and
standards, but you can't sue them if your toaster fails and burns your house
down. (Of course, in today's tort-crazed society, who knows?) The
manufacturer is ultimately liable for damages caused by design/manufacturing
defects (unless a component vendor offers a warranty on their products, such
as a tire manufacturer's warranty on the tires on a new car).

One problem I have with McConnell's "manifesto" is that the project failures
he holds up as examples are unique to the software industry, when in fact
they aren't. The "professional" engineering disciplines have had many
significant failures in recent years: NASA's Mars probes & Challenger, the
failed dams & levees along the Mississippi a few years ago, and several
airliner crashes to name just a few.

Mark

[Chad Mello]

>>What if your bug actually came from
>>a third party component? What If the bug only occurred on >>certain hardware
>>or configurations? Was it an OS problem? How about a >>hardware driver
problem?

>There is no difference between these issues and issues in civil
>engineering. To your point: what if the building materials were
>shoddy? Who would be held responsible?

There is a BIG difference here. A building does not routinely move from
one place to another, as do software applications. A brick is much simpler
than a third party component or a hardware driver. Plumbing practices are
relatively unchanged whereas software engineering techniques are constantly
changing. Your analogy of the physical world to that of the virtual world
can't be used to the extent that you are proposing.

[Craig Clearman]

Chad,

>There is a BIG difference here. A building does not routinely move from
>one place to another, as do software applications. A brick is much simpler
>than a third party component or a hardware driver. Plumbing practices are
>relatively unchanged whereas software engineering techniques are constantly
>changing. Your analogy of the physical world to that of the virtual world
>can't be used to the extent that you are proposing.

I'm always amused by the number of people in one profession who
believe that the complexity of their profession is so much greater
than any others.

Not all engineering is done on tract houses.

Ciao, Craig

[Craig Clearman]

Mark,

>One problem I have with McConnell's "manifesto" is that the project failures
>he holds up as examples are unique to the software industry, when in fact
>they aren't.

I agree.

However, one that is unique to the software industry is the prevalence
of the failures. Software projects fail at a much higher rate than any
other profession.

Ciao, Craig

[Chad Mello]

Craig Clearman <chclear@nospam.please> wrote:
>Chad,
>
>>There is a BIG difference here. A building does not routinely move from
>>one place to another, as do software applications. A brick is much simpler
>>than a third party component or a hardware driver. Plumbing practices
are
>>relatively unchanged whereas software engineering techniques are constantly
>>changing. Your analogy of the physical world to that of the virtual world
>>can't be used to the extent that you are proposing.
>
>I'm always amused by the number of people in one profession who
>believe that the complexity of their profession is so much greater
>than any others.
>
>Not all engineering is done on tract houses.
>
>Ciao, Craig
>


I am well aware of the fact that complexity abounds in many, many fields.
Complexity alone is not the issue. It's governing this particular TYPE
of complexity that's the issue. I simply can't see your argument as being
practical. Too many undefined parameters and ambiguities will always be
found within the realm of software engineering that would make it impossible
to create hard-set rules.

[Mark Newman]

Chad Mello <cmello@positouch.com> wrote in message
news:39187eb3$1@news.devx.com...
>...
> Too many undefined parameters and ambiguities will always be
> found within the realm of software engineering that would make it
impossible
> to create hard-set rules.

True enough now, and as long as that's the case there will never be a "True"
profession of software engineering. SW engineering now is at the same place
aeronautical engineering was in the early 1920's: We can usually design an
airplane that actually flies, but we can't predict its performance very
well, or how well it handles, or if another approach would result in a
better design. We have a long way to go.

Mark

[Chad Mello]

"Mark Newman" <mnewman@wavecrestcorp.com> wrote:
>
>Chad Mello <cmello@positouch.com> wrote in message
>news:39187eb3$1@news.devx.com...
>>...
>> Too many undefined parameters and ambiguities will always be
>> found within the realm of software engineering that would make it
>impossible
>> to create hard-set rules.
>
>True enough now, and as long as that's the case there will never be a "True"
>profession of software engineering. SW engineering now is at the same place
>aeronautical engineering was in the early 1920's: We can usually design
an
>airplane that actually flies, but we can't predict its performance very
>well, or how well it handles, or if another approach would result in a
>better design. We have a long way to go.
>
>Mark
>
>

Agreed. I must commend your analogy. Therefore government couldn't establish
any practical, legal guidelines until the field (software engineering) itself
is critiqued and formalized. And, like you said, we have a long way to go
before that happens.


Chad

[Matthew Cromer]

in article 38fd3d9a$1@news.devx.com, John Ellsworth at dnaarch@msn.com wrote
on 4/19/00 1:01 AM:

>
> Well, someone wants to make software engineering into a true profession by
> requiring sign-off licensing. As an ex-lawyer who now practices software
> engineering as both a developer (MCP) and web architect, I can tell you that
> the practice of law, as just one example, has certainly not been made more
> professional or "better" by allowing only attorneys to sign off. Rather,
> what this requirement has done, has taken the law away from the people, its
> real owners. Anyone care to try round 2, and improve the practice of software
> development by applying (once again) this same technique? McConnell, your
> software engineering books are excellent (even we unlicensed engineers can
> read, comprehend, and apply as required). May I respectfully suggest that
> you stick with what you know, and leave the licensing arguments up to those
> who would benefit most--the regulatory agencies and bureaucrats all too
> anxious
> to jump on your bandwagon and so disempower yet another group of process
> owners.


Obvious Steve is someone like Alan Greenspan who thinks our economy is
growing too quickly and we need to slow it down by reducing the pool of
knowledge workers.

(g,r, &d)
--
Matthew Cromer
President, SDA Consulting, Inc.
matthew@sdaconsulting.com
http://www.sdaconsulting.com/
(919) 274-0074

[Matthew Cromer]

in article m5brfs0fe3uvu01edcq4kpddjlnpm1ljdm@4ax.com, Craig Clearman at
chclear@nospam.please wrote on 4/19/00 9:02 AM:

> John,
>
>> Anyone care to try round 2, and improve the practice of software
>> development by applying (once again) this same technique? [licensing]
>
> As long as Round 1 was creating the requirement for civil engineers,
> I'd certainly expect to see benefits.
>
> Yes, I know: "post hoc ergo propter hoc." Just because the practice of
> civil engineering improved in the decades after licensing of civil
> engineers became commonplace does not mean that the improvements were
> caused by licensing. But the same argument is true for your example:
> lawyers.
>
> Overall, I enjoyed the book, but not as much as I enjoyed his previous
> works. Before anybody buys _After the Gold Rush_, you should realize
> that it is a manifesto, not a reasoned argument. For instance,
> McConnell will bring up examples of disastrous software errors. Then
> he will bring up data showing how defects decrease and productivity
> increases when you use stronger methodologies. But he does not even
> attempt tie the specific software failures to a failure to follow a
> stringent methodology.
>
> Ciao, Craig
>


I don't have any problems with his advocacy of methodic software
engineering. My only problem with his book is the concept that somehow
getting the same idiots who created Social Security to tell me how to do my
job is somehow an improvement.

OTOH, his prescription would drive our wages up by limiting competition, so
maybe we should do it anyway (lol), just like the doctors and lawyers did.
--
Matthew Cromer
President, SDA Consulting, Inc.
matthew@sdaconsulting.com
http://www.sdaconsulting.com/
(919) 274-0074