🚀 go-pugleaf

amn@unix.brighton.ac.uk (Anthony Naggs) writes:
>So what do I do that makes me an engineer?
>Well, some suggestions:
>1   Collect detailed requirements, classifying them into those which define
>    the scope of the problem, external appearance of the solution, features
>    which my client has seen elsewhere but doesn't really need/want.
>2   Specify the system, (whether in English, pseudo-code, Z, ..), including
>    specification of the required test coverage.
>3   Particularly for embedded systems and other critical applications,
>    define and agree behaviour in event of software or system faults,
>    (fail safe, fail soft, ..) - and recovery strategies.
>4   Develop a test plan to meet the requirements of 2 & 3.  Including both
>    functional and parametric tests.
>5   Break the specification into logical blocks, each with a subspecification.
>    Refine the breakdown into smaller blocks, to reach definitions for
>    programming teams, libraries, functions, as required.
>6   Refine the test plan, to include tests at each level in 5.
>7   Implement the design.  Selecting programming tools, languages to suit the
>    task.
>8   Ensure that software/system is tested in accordance with the test plan
>    before release.

>The key is to apply a sound method.

Sorry, but if this makes you an engineer then Picasso was a "paint
engineer". The link between programming and Engineering is a spurious
one invented to make clients think that we have abetter understanding
of the processes involved than we actually do. However, dont get me
wrong I am not knocking what you have outlined above - its exactly how
I would go about it myself - but what you have described is in fact
"craft" not "engineering". We have a very long way to go before
software development is an engineering skill.

>"Selecting programming tools, ..", sounds a bit heavy, but I approach it in
>the same way as I do electronics - at the micro level, selecting components
>to suit the task, such as logic ICs, audio circuits, video circuits, radio
>circuits, or humble transistors.  While a spectrum of parts/tools may do a
>task it is my duty to select the most appropriate, balancing the specification
>and cost against the requirements of the task in hand.  At the macro level
>I need test equipment that is appropriate, for example equipment that must
>comply with RF (radio frequency or electro-magnetic) emission and
>susceptibility regulations requires special test equipment and considerations.

Again this is not engineering - a painter selects her materials before
she starts work.

>Finally, I am not claiming that all my programming is 'engineering', but
>I believe that on the occasions when I use the above methods that I am
>then applying engineering principles.

There is a difference between applying engineering principles and
actually doing engineering. 

L.
MAIL :	Lindsay.Marshall@newcastle.ac.uk
POST :	Computing Laboratory, The University, Newcastle upon Tyne, UK NE1 7RU
VOICE:	+44-91-222-8267
FAX  :	+44-91-222-8572