Laws on Programming (Was: Re: [ Re: UNIX- Grad-daddy of all modern operating systems?])

[Carlos Macedo Gomes]

On 7/2/07, Alan Dayley <alandd at consultpros.com> wrote:
> 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?

Good questions, Alan.  I can definitely see your points and have
several close friends that are very much aligned with what I perceived
to be your point of view.  My point of view is somewhat different.

I'm a security engineer by training and trade so I've worked closely
w/ software engineers, SW architects, and project managers to delivery
scary^H^H^H^Hecurity products as close to schedule and budget as
feasible.  In my experience, defects detection and tracking (as part
of Quality Analysis) are part of the regime of software engineering,
security engineering, project management, and project portfolio
management.  Bugs are also defects but generally denote a "surrender"
mentality.  When engineers talk about defects it's generally w/ a look
to quantify, contain, minimize, and/or eliminate/mitigate.

Here's a quote w/in a quote from Ross Anderson's _Security
Engineering_ textbook that I think further illustrates my point.:

<quote>
'When I use a word,' Humpty Dumpty said, in a rather scornful tone,
'it means just what I choose it to mean—neither more nor less.' 'The
question is,' said Alice, 'whether you can make words mean so many
different things.' 'The question is,' said Humpty Dumpty, 'which is to
be master—that's all.'

It is important for the security engineer to develop sensitivity about
the different nuances of meaning that common words acquire in
different applications, and to be able to formalize what the security
policy and target actually are. That may sometimes be inconvenient for
clients who wish to get away with something, but, in general, robust
security design requires that the protection goals are made explicit.
<quote from http://www.cl.cam.ac.uk/~rja14/Papers/SE-01.pdf>

> > 2. There are two types of defects: Design and Implementation.
> > a. Design defects are a direct reflection on the Software Architect's
> > b. Implemetation defects are a direct reflection on the developer's
>
> 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.

Not to split hairs, but your "c." above sounds more like a Project
Management problem (i.e., scope/quality, schedule, and/or cost) to me.
 As software engineers and project managers (and program managers)
become more capable, finger pointing to SW folks for issues related to
code/products with defects decreases (if not diminishes).  One of the
main goals of Project Management (and Portfolio Management) is to
reduce (not eliminate) the likelyhood that a SW project will not meet
expectations and to allow customers/management accept the risks of
accepting the project/assignment.  The practice of detected and
resolving defects generally does not include blaming individuals (not
sure if finding "bugs" does either).  Root-cause analysis for serverly
failed projects might lead to issues w/ staffing appropriate resources
but that again is a PM problem (aka tracked risk of lack of adequate
resources).

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

[redacted examples of non-certified and certified software folks]

I agree w/ your examples.

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

I think you don't give enough importance to what you term "niche
products".  Here's an metaphor that might help: A tree's leaves are
more numerous and visible than the branches and the trunk, but with
every seaon new leaves are born from the same branches and single
trunk.  Desktop apps (and now Web Apps) might be more numerous and
buggy but in general, but the overall computing software trunk or
software branches (what I believe you call "niche") involve more
effort in development and are hopefully less frought with defects
(otherwise the tree should die).  So certain FS/OSS apps might have
defects but the core algorithms and platforms should still survive.
Same w/ MS.  Over time the trunk and branches should become less
defect ridden especially as stems and smaller branches evolved into
more mature branches.

In other words, without the engineering examples, applied coding
examples, research, and development  into OS's, algorithms,
cryptography, networking, etc. we wouldn't be where we are today.  And
we're not done by any stretch.

In other words, I'm personally and professionaly not ready to give up
on good engineering, architecting or coding because the current
landscape (aka marketplace) has gotten used to large numbers of
defects.  To do so would leave to very weak and ugly forests for the
future.

> 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'm a big fan of FS/OSS and the lessens learned in that space.  They
are truly revolutionary.  You can also leverage Agile development
techniques (i.e., Extreme Programming) in a formal business
environment that can support it culturally and financial.   Google (at
least in the early days) is a modern example of "chaotic" develpment
leveraging engineering discipline for profit (and pro bono).  The
future will give rise to many more examples like this.  Good
engineering does not need to be slow and beauractric.  Think about the
scene in Apollo 13 when the ground crew (engineers and scientists)
have to create solutions on the ground for problems in space.  If
that's  not an example of good engineering in a "chaotic" or extreme
mode I don't know what is :-)

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

In my experience, good (aka effective and mature) Project Management,
Program Management, and Portfolio <anagement help to set expectations
about code projects that might run amock allowing mgmt/customers to
decide on whether to take the risk.

> 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

The Wright brothers were, among other things, successful bycicle
makers when they made their first airplane.  I seriously doubt the
quality controls, development discipline, and engineering skills in
place for that project would be considered sufficient for modern
passenger aircraft (or military aircraft).  You still have people
building their own airplanes/gliders and personal pilotting is a
growth industry in the US but the large part of the aviation industry
is maintained economically by good engineering and competition.  Same
can be said for the auto-industry.

I'm a big believer in William Gibson's quote that (to paraphrase) the
street will find use for technology.  And when the tech is extremely
flexible (like TCP/IP enabled apps based on IA32/IA64 architectures
are today), that testing ground does come with alot of chaos.  But I'm
also a fan of attempting to understand chaos and possibly even harness
it where possible.

ymmv,
C.G.

-- 
powerofprimes at gmail.com
Carlos Macedo Gomes
_sic itur ad astra_