Steve McConnell book, Software Engineering as a...blah blah - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 2 FirstFirst 12
Results 16 to 20 of 20

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

  1. #16
    Matthew Cromer Guest

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

    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




  2. #17
    Matthew Cromer Guest

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

    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.

    --



  3. #18
    Mark Newman Guest

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


    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)




  4. #19
    Jim VanHook Guest

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

    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



  5. #20
    Craig Clearman Guest

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

    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


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center