Carlos Macedo Gomes wrote:
>
> I like these laws even better:
>
> George's Laws on Programming
>
> 1. There is no such thing as a programming bug. A bug was the moth that
> Grace Hopper pulled out of her vacuum tube computer. What programmers
> like to call bugs are defects - defects in workmanship - defects in
> quality.
A rose by any other name...
Why do you feel it is important that defects are not called bugs?
> 2. There are two types of defects: Design and Implementation.
> a. Design defects are a direct reflection on the Software Architect's
> inability to properly design a robust program, or to interpret Business
> Requirements.
> b. Implemetation defects are a direct reflection on the developer's
> inability to either do what he/she is told, or his/her inability to ask
> questions about requirements they do not understand.
I'd add:
c. "Features" or design requirements that are not reasonable to
implement and yet are demanded by people in charge. I include in this
unrealistic deadlines, limited time budget for testing or other work and
other decisions made by those not doing the work.
> 3. When software defects kill people, the Software Engineering industry
> will have no choice but to become a credible engineering discipline like
> mechanical engineering, electrical engineering, and architecture with
> the accompanying reviews and professional certifications.
I don't believe this will ever happen, in general. Let me explain.
A. Software used in places that could kill people is already covered
under various standards of scrutiny and "credible engineering
discipline." Quick examples:
Aircraft software:
http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/what_is_air_software/
Defense:
http://en.wikipedia.org/wiki/MIL-STD-498 replaced in 1998 by
http://en.wikipedia.org/wiki/IEEE_12207
Medical devices:
http://www.ieeeboston.org/edu/2007spring/course_sw_for_med_dev.htm
(The above are just quick hits that point or infer to various standards
of development process and documentation for these industries.)
Software engineers who work in these fields are already required to
follow various disciplinary practices while creating their software.
There is little incentive to bring all software engineers into such
practices.
B. Software is a commodity. MS has used it's market dominance to
maintain it's high prices but the reality is that every day software is
more and more of a commodity. Except for specific niche products, it is
no longer a viable business model to use "traditional" high discipline
practices to create software. It would cost far too much for the market
value. FS/OSS is embracing this reality and continues to drive general
market pricing downward. Even with out FS/OSS, this trend would still
occur because the production cost of software, once written, is almost
nothing.
C. The value of harnessing "chaotic" software development is huge.
Witness the Linux kernel. The cost to develop the 2.6 version of the
Linux kernel is estimated at between $176M and $612M
(
http://www.dwheeler.com/essays/linux-kernel-cost.html for one report).
And that is just the value of only the kernel! Full engineering
discipline required of all software developers would be a barrier to
harnessing such value.
I can think of a few other minor reasons, like: The high changeability
of both the requirements and software. Or that software development is
more about communication that it is about hard processes. But the above
are at the top of the list.
With the continued growth of FS/OSS, I think the software development
profession will continue to proceed down the path toward something like
plumbers or carpenters. There will be "stars" in the field that create
new and interesting "pipe fittings" or "truss braces." And there will
be some who are "real engineers" with full discipline because of how the
software they write will be used. But most people working as software
developers or software engineers will simply be earning a decent living
putting the known pieces and processes together for people who need
something out of the ordinary. And that is not a bad way to make a living!
Alan
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)
