[Top] [All Lists]

Re: [ontolog-forum] Software as art, metrics, etc.

To: edbark@xxxxxxxx, "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ron Wheeler <rwheeler@xxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 25 Feb 2010 14:40:20 -0500
Message-id: <4B86D224.60007@xxxxxxxxxxxxxxxxxxxxx>
Edward Barkmeyer wrote:
> 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.
> 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.
> Let me explain briefly how the engineering process for a complex system 
> works: 
> 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.
> 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.
> 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.
> 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.
> 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. 
> 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.
> 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.
> 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.
> 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.
> 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.)
> -Ed
> "Safe upon the solid rock
>  The ugly houses stand.
>  Come and see my shining castle
>  Built upon the sand."
>   -- Edna St. Vincent Millay
> P.S.  Yes, I should put this on the wiki, because this is a soapbox I 
> have been on for 20 years.
It may be a bit outside the topic of Ontology but worth a place on the wiki
> 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.
>       (01)

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    (02)

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