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