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

[Matthew Cromer]

in article 39199f0d@news.devx.com, Mark Newman at mnewman@wavecrestcorp.com
wrote on 5/10/00 1:43 PM:

>
> 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
>
>
>
>


This is because the rate of change in the art of software development is
orders of magnitude greater than almost any other field.

The difference between the architecture DOS and Windows 2000 is tremendously
greater than the difference between the Boeing 747 and 767 airplanes,
although a similar time spread existed between each systems earlier and
later design.

It's as if our jet engines doubled in horsepower every two years, got twice
as efficient, Aluminum dropped in price by half, gas cost half as much,
maximum speed doubled, etc. Over two decades we would be flying to other
galaxies, if aviation had improved at the rate of computer technology.

OTOH, it is true that large segments of the software development community
aren't using these innovations and are writing code the same way today as
people did 20 years ago.
--
Matthew Cromer
President, SDA Consulting, Inc.
matthew@sdaconsulting.com
http://www.sdaconsulting.com/
(919) 274-0074

[Matthew Cromer]

in article t0uahsg13833amrin4djcfggjanhaaapmj@4ax.com, Craig Clearman at
chclear@nospam.please wrote on 5/7/00 10:07 AM:

> 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
>

Here is my manifesto as to why projects fail:

1. Non-technical people determine the feature set and the delivery dates
and the personnel requirements on projects. This is ludicrous. Development
teams should determine some of these factors on every project. The people
responsible for writing the code should have buy-in to these numbers. This
issue is a direct cause of much of the rest of the items I mention below.

2. Architecture work is not done. The average business software product is
thrown together in a manner which defies common sense. Like any other
complex system, software development products should be designed and
engineered rather than accreted like a dirty snowball rolling down a slope.
Developers should look at possibilities to write common code, reuse code,
create reusable objects, increase encapsulation, reduce coupling, and make
other design decisions that improve software quality and reliability. Every
software programmer should know about the fact that finding a problem at the
architecture level is an order of magnitude cheaper to solve than finding it
during construction, and two orders of magnitude better than finding it out
at deployment time. And yet we continue to code-and-fix instead of
planning. Would you build an airplane without designing it first? Software
development projects are unbelievably expensive and it boggles the mind so
many are started with open code windows in the IDE instead of thought,
discussion, prototypes, and other such non-coding activities.

3. Lack of self-training. Many developers are willing to write software
for money but consider it too much to learn more about their field, to
subscribe to the trade magazines, to participate on online fora, and
otherwise better their abilities. This doesn't lead to improvements in
software quality. I especially target the lack of knowlege of Object
Oriented software designs and techniques that many programmers have.
Quality OO software design and construction can lead to 100-200% increases
in productivity and code quality even for good developers.

4. Lack of peer supervision and review. Every team of two or more
developers should conduct code reviews, preferably weekly. Most software
organizations don't do it. The software review process is essential to
helping everyone write better code and getting more consistent, quality
code. It is more effective at finding bugs than testing is!

5. Lack of willingness to pay for quality. Most project managers and
customers are not looking to hire the best people for their projects. This
is insane. Top-notch developers are entire orders of magnitude better than
mediocre ones, they write more code, their code does more, it is more
reliable, their designs are more scalable and reusable, and they get stuff
done more quickly. Yes, when you are hiring an employee to serve big macs
in McDonalds this is more or less a commodity. Software engineers,
programmers, architects, etc. are absolutely not commodity items. You
should hire the best people you can possibly pay for, expect to pay them
twice the commodity rate and expect them to deliver five times the value.
How many software organizations are willing to pay a 50% premium for
software talent, much less a 100% premium? Not many, I can assure you.
Other ways to "pay" talent include allowing offsite work, allowing remote
development.

6. Poor infrastructure. As a professional software developer, I have been
in situations where I didn't even have a cubicle, much less an office. I
sat at a desk in a hallway, and all day long people would walk by me on the
way to the bathroom. This is a terrible way to waste money. It also is
very demotivating.

7. Lack of attention to testing / QA before shipping. Often barely a week
is allocated to testing a product.

8. Lack of communication with the clients about the software and the needs
of the clients. This is a tremendous problem in many software development
organizations

9. Terrible UI design. Many UIs are developed for geeks by geeks that only
a geek could love. This is rudeness of the highest order, and it is costly
and even dangerous as well. I'm a hardcore software coder who will delve
into the depths of COM multithreading, but I still get stumped programming
my electronic gadgets and their wretched UIs.

--

[Mark Newman]

Matthew Cromer <matthew_cromer@iname.com> wrote in message
news:B5409E8D.C493%matthew_cromer@iname.com...
> in article 39199f0d@news.devx.com, Mark Newman at
mnewman@wavecrestcorp.com
> wrote on 5/10/00 1:43 PM:
>
> >
> > 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
> >
> >
>
> This is because the rate of change in the art of software development is
> orders of magnitude greater than almost any other field.
>
> The difference between the architecture DOS and Windows 2000 is
tremendously
> greater than the difference between the Boeing 747 and 767 airplanes,
> although a similar time spread existed between each systems earlier and
> later design.
> ...
>

Well, analogies can only go so far, and here we are at the end of this
one;^) Airliners are far more complex than Win2000 and have a *far* higher
quality standard that Win2000, for rather obvious reasons. If the
software/pc industry had to meet those standards we'd still be running DOS
3.3.

In truth, aeronautical engineering has experienced periods of rapid growth
just as profound as computer technology. For example, the DC-3 was entering
widespread service in the mid-30s; 25 years later the 707 debuted. Gigantic
differences in design & performance.

Yet, some sixty-plus years later, the DC-3 is still in worldwide use, while
only a few non-military 707s are still flying. Eloquent testimony to the
design of the DC-3, the greatest plane ever!

Mark (who always looks up at a passing airplane)

[Jim VanHook]

Craig -


> 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.

We hear this all the time. I wonder if it's really true. For example, if I
have a house built, and in two years time some portion of the house doesn't
hold up... say the floor sags just a bit. What is the consequence? Maybe a
crack in the drywall, or a small gap between floor and wall, or a buckle in
the vinyl flooring. Is that a failure? Do we count it as such? I doubt it,
because the consequence is small. But this defect could have arisen from bad
site engineering, shoddy workmanship, improper material selection...

Do we have a software equivalent? How about a missing error handling
routine, that isn't normally called upon? Or a timing issue? Or, you fill in
the blank. What is the potential consequence? It could be quite high. If it
was a particularly difficult problem to diagnose and resolve it could mean
major rework and even scrapping.

So what I wonder is whether there is a disproportianate relationship between
the severity of the error and the severity of the consequences in software
that is responsible for the higher failure rate.

- Jim

[Craig Clearman]

Hi Jim,

>> 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.
>
>We hear this all the time. I wonder if it's really true. For example, if I
>have a house built, and in two years time some portion of the house doesn't
>hold up... say the floor sags just a bit. What is the consequence? Maybe a
>crack in the drywall, or a small gap between floor and wall, or a buckle in
>the vinyl flooring. Is that a failure?

No, not in the terms that we are using. It is a defect, instead. A
failure of the project is the failure to deliver on time and on
budget. A defect is the quality issue that occurs after delivery.
Defects could be either known or unknown at the point of delivery, but
they do not count in the statistics of project failures.

I'm not sure if there are any statistics concerning defect rates that
cross professions. I certainly have never seen them. I suppose it
would be possible to gather the information, but the defects would
have to be measured by the cost to fix the defects to determine the
severity of the defect, and the cost of the project, which would be
the balance.

In truth, I don't know whether there is a higher defect rate in
software. My guess would be yes, but I'm not sure at all. One thing
that is clear, though, is that there is a *large* distribution of
defect rates inside our industry. Some software projects have
minuscule defect rates, where others have defect rates so high that
the software delivered can easily be called unusable.

Ciao, Craig