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

[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