    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
     <channel>
        <title>ACCU  :: Editorial</title>
        <link>https://members.accu.org/index.php/articles/725</link>
        <description>Professionalism in Programming</description>
        <dc:language>en-us</dc:language> 
        <dc:creator>Administrator</dc:creator> 
        <admin:generatorAgent rdf:resource="http://www.xaraya.org" /> 
        <admin:errorReportsTo rdf:resource="mailto:webeditor@accu.org" />
       <sy:updatePeriod>hourly</sy:updatePeriod>
       <sy:updateFrequency>1</sy:updateFrequency>
       <docs>http://backend.userland.com/rss</docs>




<div class="xar-mod-head"><span class="xar-mod-title">Journal Editorial + CVu Journal Vol 8, #2 - Apr 1996</span></div>

<table border="0" cellpadding="1" cellspacing="0">
    <tbody>
    <tr>
        <td valign="top">
            Browse in :
       </td>
       <td valign="top">

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c184/">Journal Columns</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c185/">Editorial</a>
<br />

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c76/">Journals</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c77/">CVu</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c136/">082</a>
<br />

                                            <a href="https://members.accu.org/index.php/articles/c185-136/">Any of these categories</a>

                    -                        <a href="https://members.accu.org/index.php/articles/c185+136/">All of these categories</a>
<br />
</td>
   </tr>
   </tbody>
</table>




<div class="xar-error">
   <p>
 <strong>Note:</strong> when you create a new publication type,
the articles module will automatically use the templates
<em>user-display-[publicationtype].xt</em>
and <em>user-summary-[publicationtype].xt</em>.
If those templates do not exist when you try to preview or display a new article,
you'll get this warning :-)  Please place your own templates in themes/<em>yourtheme</em>/modules/articles . The templates will get the extension .xt there. </p>
</div>
<div class="xar-norm xar-standard-box-padding">
   <h1><strong>Title:</strong>&nbsp;Editorial</h1>
<p><strong>Author:</strong>&nbsp;</p>
<p>
<strong>Date:</strong> 09 April 1996 13:15:27 +01:00 or Tue, 09 April 1996 13:15:27 +01:00</p>
<p><strong>Summary:</strong>&nbsp;</p>
<p><strong>Body:</strong>&nbsp;<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e18" id="d0e18"></a></h2>
<h3>A New Year Meditation</h3>
</div>
<p>For a long time (at least ten years) I have been trying to put
my finger on a sense of disquiet that I have when using phrases
such as 'professional programmer'. From time to time I meet highly
skilled and very knowledgeable programmers who are clearly both
expert and professional in their work. The problem this causes me
is that they seem to expect the skills and professionalism of
others to be measured against their criteria. What they have to say
about such things as using a formal specification language, proving
code, proper design methods preceded by a detailed analysis,
identifying the problem domain and much more, seems entirely
reasonable until they wish to apply this to everyone.</p>
<p>I am quite clear in my own mind that there are 'cowboy'
programmers at all levels. However I do not think that a failure to
use any specific technique can be used as a criterion to identify
these. As a great deal of emotional heat can be generated by
discussing what makes a professional programmer let me consider an
entirely different discipline, that of woodworking.</p>
<p>DIY woodwork such as making your own bookshelves does not mark
you as incompetent. However it does not qualify you to earn your
living at woodwork, though it is possible to move from the being a
good, competent DIY woodworker to some form of 'professional' (in
the sense of justifiably earning money for it) woodworker.</p>
<p>One of the features of many DIY woodwork is inappropriate level
of perfection. The ignorant have no idea about the job, know
nothing about the qualities of different joins etc. and inevitably
produce the classic DIY botched job, wasting materials and time
(and even sometimes failing to appreciate just how bad their work
is). There is an opposite failure with some DIY workers, they do
not know when robustness delivered in a timely fashion is more use
than elegance delivered late. They are trapped by the concept of
taking a pride in their work and finish up by sanding the joists
before laying the floorboards. What is worse is that they have
probably laid the floor for their DIY roof-conversion on ceiling
joists but that is another issue (doing the wrong thing to
inappropriate standards).</p>
<p>Note how a slid from bookshelves to floor joists. Both entail
forms of woodwork but the problem domain is quite different. Quite
apart from the overt differences there is the vital aspect of
safety. If you botch a job of making some shelves the result is
usually an ugly mess that fails catastrophically at some stage
without doing too much extraneous damage. If you botch the job of
providing joists for your roof conversion the result may hold
together for several years before finally failing catastrophically
and literally bringing your house down.</p>
<p>Whittling a figurine from a piece of driftwood may require as
much skill and artistry as making an elegant piece of furniture but
they require different tools and different techniques. The outsider
may see both as artistic woodwork but those with more insight will
recognise that the expert practitioner of whittling is unlikely to
be an expert cabinet maker. The tricks of one trade are
inappropriate to another.</p>
<p>Consider the musical instrument maker. Those making guitars,
violins etc. will share many skills with the cabinet maker,
none-the-less their point of focus will be different. They will
want to produce a beautiful instrument, but above all else it will
have to produce a beautiful sound. Those who specialise in woodwind
instruments will probably share far more skills with the whittler,
yet here again the primary criterion will be one of sound. A deaf
cabinet maker or figurine carver is quite believable, a deaf flute
maker is beyond belief.</p>
<p>Note that all these woodworkers need to understand such things
as 'grain' though in different ways. The cabinet maker has to
understand its influence on structural strength and ways of using
it aesthetically. The instrument maker has to understand how it
influences the resonance of an instrument while the whittler must
not only appreciate how to work with it to produce a beautiful
result but must also know how it might dangerously turn a
knife.</p>
<p>The best teachers of basic woodworking skills understand a
little of all the variety of woodworking jobs, enough to direct
their students along profitable paths of study and practice.</p>
<p>Let me leave woodwork (at which my best leaves much to be
desired) and mention another 'craft' of which I know a little more,
that of rope-work or 'knots'. The most authoritative work on knots
is 'The Ashley Book of Knots' (Clifford Ashley - my 1977 reprint
[ISBN 0571 09659 X] of the 1960 edition cost &pound;12-50). One of
the points that Ashley makes is that a knot is more than the
finished product, it has a purpose and the way it is tied may
depend on that purpose. Both mountaineers and sailors use a bowline
but the more knowledgeable of each group tie their bowlines quite
differently from each other.</p>
<p>The major purpose for a reef knot was for tying reefs into
canvas sails. In this context you can only truly claim to be able
to tie a reef knot if you can do so in pitch darkness 50 feet from
a heaving deck with your feet precariously grasping a foot-rope
whilst being lashed by torrential rain. Of course it would be
completely unreasonable to require this level of expertise from a
small dinghy sailor taking his RYA dayboat exams.</p>
<p>There is a question of maintenance. Twenty years ago I spent
most of an evening with a crochet-hook eye-splicing a lanyard to a
pin on a Cunningham block. The lanyard was made from artificial
fibres (Dacron or some such) and was plaited. That particular piece
of gear outlived my ownership of the boat - it was still in use by
the current owner last summer. The way that any professional would
have fixed the lanyard to the block would have failed years ago but
the professional does not have the luxury of taking hours to do a
life-long job.</p>
<p>I wrote the last few paragraphs with malice aforethought. I
deliberately include sailing jargon that probably means very little
to you, by way of reminding you of how easy it is to use terms that
only communicate to those that speak the same language. I also
wanted to demonstrate that such problems as maintenance and
durability are not just problems for programmers. Hobbyists can
afford to take the time needed to keep such things as the old
Thames Barges running, no professional boat user could do so.</p>
<p>However that is not an excuse for a botched job. In my younger
days I used to run outdoor pursuit camps on a regular basis. If you
have ever done very much camping you will be familiar with the mess
that such things as guy-ropes get into. Replacing warn-out ropes
(preferably before your tent blows away in a storm) can be costly
but the sad thing is that most of the wear is a result of abuse by
using unsuitable knots. This abuse is perpetrated by regular users
who are so pre-occupied with climbing mountains, canoeing
whitewater or whatever that they have neglected to learn how to
care for such fundamental equipment. I can remember having a group
I was in charge of spend an entire Sunday afternoon recovering an
army mountain rescue teams camp equipment after a vicious storm -
they had pitched camp halfway up Snowdon on the outside of a bend
in a stream (even if you have never camped, think what happens when
a stream floods).</p>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e48" id="d0e48"></a>Back to
Programming.</h2>
</div>
<p>My purpose in writing this editorial is to try to get you to
focus more on appropriate solutions and coding styles. I see far
too many dogmatic declarations of 'the right way' to do something.
It is easy to criticise the inexperienced back-bedroom programmer
but before you do (or may be you are one) stop and ask yourself if
your criticism is justified against what that programmer is trying
to achieve. I really do not think that some of the methods being
advocated on accu.general, in some letters to the editor and in
some articles are appropriate to the talented amateur, let alone
the struggling novice. Equally, I am extremely disturbed by the
coding methods being used by some in 'high integrity'
environments.</p>
<p>The programmer who advocates formal design methods to write a
program for calculating lottery numbers is as silly as one who
ignores formal methods when developing an operating system. Those
who would apply the same standards to coding an operating system
(you choose your own favourite), a development package (such as a
C++ IDE) and application (such as a word-processor) are
professionally incompetent. Anyone who tries to produce any one of
these commercially without first drafting a requirements
specification does not deserve to remain in the software
business.</p>
<p>Strong words, I know, and ones that some people may think are
directed towards them. If you think that, you are probably
right.</p>
<p>In the murky depths of my mind their lurks a half-formed concept
of a maturity model for programming. One of the important messages
that comes across in the SEI Compability Maturity Model (for
software engineering) is that progress is made step-by-step. Set an
attainable target and a plan for achieving it. We need something
similar for the individual programmer. If we can at least agree
that being able to program is not a boolean qualification (you can
or you can't) but a continuum with way-stations that can be
achieved in succession then we have some hope of improvement.</p>
<p>I wish I had the time (and the funding) to develop a full
fledged programming maturity model. However the lack of such should
not be an excuse for us to continue to stagnate. I would like to
hear your ideas on this subject. A good starting point would be to
try to specify your own current position as a programmer and where
you would like to be this time next year. Spend a few minutes
putting this in writing and then send it to me. I'll write an over
view of your responses.</p>
<p>I have a suspicion that it will be the novices and hobbyists who
will respond to this. But if this is the case, then the rest of you
will have missed the point. All of us have progress to make but
unless we can identify a direction to set out in we are unlikely to
make more than random progress out of pure chance.</p>
</div>
</div>
</p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
