ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Software as art, metrics, etc. (was: MVC)

To: Duane Nickull <dnickull@xxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Edward Barkmeyer <edward.barkmeyer@xxxxxxxx>
Date: Thu, 25 Feb 2010 12:01:04 -0500
Message-id: <4B86ACD0.3060300@xxxxxxxx>
Duane Nickull wrote:
> As long as the software meets the core metrics, there is a lot of freedom on 
>how you actually write the code.
> Code can be written in a manner that is intuitive to read and executes the 
>fastest it can or it can be written in a manner that is ugly and doesnít catch 
>exceptions etc.  Both will work but the artist is the one who designs the 
>module (assuming OO) in manner that when others look at it they appreciate it. 
> Simple, elegant, efficient, complete, strongly typed and functional.
>
> It takes both designers and engineers to build an airplane.
> My code is beautiful.  If it makes anyone cringe, so be it.  You donít have 
>to look at my source.
>       (01)

Some of my code is beautiful in my eyes, and that and $4 will get me a 
cup of coffee at Starbucks.  My most successful code, however, was plain 
of face and relatively mundane of design, but reliable as hell.  It had 
to be -- it supported the activities of a major mortgage broker, and 
someone did have to look at my source: their COBOL maintenance 
programmers had to be able to read it and change it.    (02)

Let me explain briefly how the engineering process for a complex system 
works:     (03)

1.  The overall design is developed by a team, and broken down into 
separate components with specified functions and agreed-upon 
interfaces.  The 'core metrics' are inputs to this process -- the 
required performance of the system -- and they give rise to metrics for 
the components.  This engineering activity is just emerging from the 
"black art" stage, as systems engineering becomes an organized 
discipline.  Like building architecture, part of this activity is 
artistic design, but a lot of functional buildings don't have much art 
about them, and the same is true for modern software systems and complex 
electro-mechanical systems with software elements.    (04)

2.  An individual engineer is charged with implementing a component per 
the specification for that component.  And he does this, using his 
abilities, and perhaps his sense of beauty, performs whatever tests he 
does, and submits the component with his documentation to review.    (05)

3.  A reviewing engineer looks at the code to determine if it apparently 
performs per the specification, notes any unidentified failure modes, 
etc.  If the reviewing engineer can't determine what some part of the 
code does, or how it meets the specification, they have a powwow and the 
code gets signed off when both are satisfied.    (06)

4.  A reviewing engineer looks at the code to determine if it conforms 
to company standards of practice and standards of documentation.  If it 
doesn't, it goes back to the originating engineer for repair in the 
indicated ways, and we return to step 2.    (07)

5.  A test engineer runs a set of tests of the code in isolation to 
determine that it performs according to specification under standard and 
edge conditions. If it fails, it goes back to the originating engineer, 
with a failure report, and a fault analysis.  In many cases, the fault 
analysis is done jointly with the originating engineer and the technical 
review engineer.     (08)

6.  A test engineer embeds the code in the subsystem it was designed to 
fit in and tests the subsystem and the code "in place", under standard 
and edge conditions.  If there is a failure, the failure mode is 
analyzed and documented, the relevant interface specifications are 
modified and clarified, and the affected code units are sent back to 
step 2, with the revised specifications.    (09)

That is why aircraft don't crash under computer-controlled landing.  And 
this process can still fail to identify some interface specification 
problems, or bizarre failure modes, which is why the Mars lander crashed 
and Toyota has recalls, and why aircraft companies have beaucoup insurance.    (010)

Now, how much of that is art?  And how much of that can the originating 
engineer be proud of as his?  The answer is:  if his code embodies a 
patentable algorithm, or provides the software support that enables the 
functioning of a patentable mechanism, he has a right to be proud, and 
the company will reinforce that.  That is an engineering achievement.  
Otherwise, he is usually happy if the damn thing gets through all of the 
review phases with a minimum of "ugly" rework, because that is the 
performance measurement his boss will be applying to his work, and that 
in turn is because that is the KPI for return on investment in him as an 
engineer.    (011)

This is the engineering mindset that creates wealth.  If you can couple 
that with your artistic sense, great, but a lot of important software 
engineering is not artistic, it is mundane.  The art is in the 
architecture of the system, not in the code.  When Don Knuth wrote the 
"Art of Computer Programming" series in the early 1970s, his intent was 
to make programming an "engineering art" -- a skill based on a set of 
well-defined best practices.    (012)

Now, if you are still building one-man-band software in your basement, 
none of this applies, but you are still pursuing a 20th century market.  
(Not to put too fine a point on it, when I bring up Acrobat or 
Photoshop, it lists 50 contributor names -- they are complex software 
systems.)    (013)

-Ed    (014)

"Safe upon the solid rock
 The ugly houses stand.
 Come and see my shining castle
 Built upon the sand."
  -- Edna St. Vincent Millay    (015)

P.S.  Yes, I should put this on the wiki, because this is a soapbox I 
have been on for 20 years.    (016)

P.P.S.  The relevance of this to knowledge engineering is this:  
Knowledge engineering is still a "black art" -- it is about individual 
skills and insight and beauty.  But, if it is to become a success on any 
useful scale, it must become an engineering discipline.  And that in 
turn requires established technologies and accepted best practices.  I 
think we are finally beginning to see the technology establishment, but 
we have a long way to go on best practice, and belief in the preeminence 
of beauty will not help us get there.    (017)

-- 
Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (018)

"The opinions expressed above do not reflect consensus of NIST, 
 and have not been reviewed by any Government authority."    (019)


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (020)

<Prev in Thread] Current Thread [Next in Thread>