Actually – I’d encourage you to put this on the wiki. It is a nice summary.
Duane
PS – I have never tried to exchange code for a drink at Starbucks. Interesting idea ;-P
On 2/25/10 9:01 AM, "Edward Barkmeyer" <edward.barkmeyer@xxxxxxxx> 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.
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.
--
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
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."
---
Adobe LiveCycle Enterprise Architecture - http://www.adobe.com/products/livecycle/
My TV Show - http://tv.adobe.com/show/duanes-world/
My Blog – http://technoracle.blogspot.com/
My Band – http://22ndcenturyofficial.com/
Twitter – http://twitter.com/duanechaos
_________________________________________________________________
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 (01)
|