Journal Articles

CVu Journal Vol 8, #2 - Apr 1996 + Journal Editorial
Browse in : All > Journals > CVu > 082 (9)
All > Journal Columns > Editorial (221)
Any of these categories - All of these categories

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. 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/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: Editorial

Author: Administrator

Date: 09 April 1996 13:15:27 +01:00 or Tue, 09 April 1996 13:15:27 +01:00

Summary: 

Body: 

A New Year Meditation

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.

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.

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.

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

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.

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.

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.

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.

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.

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 £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.

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.

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.

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.

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

Back to Programming.

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.

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.

Strong words, I know, and ones that some people may think are directed towards them. If you think that, you are probably right.

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.

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.

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.

Notes: 

More fields may be available via dynamicdata ..