[ Re: UNIX- Grad-daddy of all modern operating systems?]

[Bryan O'Neal]

Personal opinion, George was far too brutish and overly simplistic for
the reality that is software development.  Indeed I would wounded if he
ever managed a single wind spread development project.

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. 
   - Words change, it may not be pleasant to think of it but it is true.
I remember when Intel's "pretty" them song end with pretty, witty, and
gay not bright, because at the time, and for a short few hundred years
prior, gay meant happy and care free, not homosexual.  Words change,
meanings change, the world changes, and I too feel we should teach
popper English and grammar and eliminate colloquialisms when possible.
However, once a word has been added or changed in Webster's and the OED,
it is almost certainly a lost battle.  Language is a collection of
sounds or symbols that facilitate communication through common meaning.
If 99.997% of the people you need to talk to call this a bug, it is a
bug.

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. 
Perhaps someone's inability, but you must understand at least two
things, 1) Software Architects don't dictate the robustness of a
program, they only implement it.  Robustness often costs and is not
required.  If my market for a product is for a small English only group,
is a defect that is was not designed to be easily translated to French?
If it did not meet the original design and testing specifications then
it would never get out to the public.  Should you say that nothing is a
defect simply because it was not planed for, or should plan for
everything and never release a program?  You make the assumption people
know their business requirements and understand how to implement them
using rigid logic.  Remember, software design is a business, if you do
as asked you get paid, even if it is ridiculous.  It is not the software
designers job to fully understand the business process, just like it is
not an architects business to understand why you want a specific design
element. If you decide you want a house that looks like a giant piece of
steaming animal waste, the it is the architects job to bring your dream
to life, just as you asked for it.  HE may point out that it looks like
crap, and that certain things like solar gain and water drainage can be
more efficiently handled by other designs, but if the client says that
they want crap, that is what they will get, with no absolution.

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.
Again, you make the assumption that the people they are asking questions
to know the answers.  Or that they even know the questions to ask.  If
you design an application and you ask "hey are there any government or
agency regulations I need to know about?" and get a no, well it is not
their job to look any further.  If it was then they would be an industry
lawyer not a software designer.  All parties involved should do what
they can to know all points and facilitate understanding, however you
must also understand where your time is best spent and what the scope of
your work is.  If the people who want the software say, "I don't know,
could you find out?" then the software developer should get a quote from
an industry lawyer and pass it up, but the hundreds of hours used to do
the research your self would bring incomplete results and waste your
budget.


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. 
That is like saying every person who hangs dry wall needs to be a
licensed civil engineer.  The people who need to be are, and the people
who are not are not.  But it is the responsibility of the buyer to
understand that they can not higher an unlicensed general contractor to
designee and build a commercial high rise.  Nor should you pay a
professor in fluid dynamics to unclog your toilet.  There is not one
stander because there is not one kind of software.  The world is
complex, get over it.  Do I believe the that society for professional
engineers will one day license software engineers...  Maybe, but more
likely they would license computer engineers who would then specialize.
And that is a ways off, right now there are a number of engineering
disciplines that are purely state regulated, such as Fire Protection.
Really, much outside Civil, Electrical, Mechanical, Chemical,
Industrial, Environmental, and Aerospace, don't bank on seeing it any
time soon.
This sort of reminds me of one of my engineering professors though; the
first day of class he looked out across the room and said "I am sure
many of you think you will get an 'A' in my class.  What is an A?  90%?
If you strive and achieve a 90% you should get an 'A' right? Wrong your
engineers! If you get it 90% correct 10% of all the planes fall out of
the sky at any given time and you are responsible for the deaths of
hundreds of thousands of people!  Your playing with peoples lives now,
you need to be 100% correct at all times to even pass my class!
(Indecently I think with the curve an 'A' was 65% or better ;)
Of course my static's professor's favorite exercise was giving you a
bridge design and seeing who could cut the most material out and keep it
standing.  The goal was usually 10% cost savings or better without total
collapse per the recommended design factors. :)



ymmv,
C.G.
On 7/1/07, George Toft <george at georgetoft.com> wrote:
http://georgetoft.com/georgeslaw.shtml