That is a great description of what engineering is. When I first started
work as an electronic engineer, it was a given that one could expect to
spend a small amount of one's working day actually soldering resistors
into boards and calculating h parameters and the like; the rest is
engineering, that is connecting the clever stuff we do with the
generation of business value at minimum risk to life and property. (01)
For some reason, this is not beaten into people who learn software
engineering, in the same way it is beaten into the rest of us who
pursued a career in turning stuff we enjoyed doing into engineering. (02)
Mike (03)
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.
>
> 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.
>
> (04)
--
Mike Bennett
Director
Hypercube Ltd.
89 Worship Street
London EC2A 2BF
Tel: +44 (0) 20 7917 9522
Mob: +44 (0) 7721 420 730
www.hypercube.co.uk
Registered in England and Wales No. 2461068 (05)
_________________________________________________________________
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 (06)
|