Journal Articles

CVu Journal Vol 12, #6 - Dec 2000 + Journal Editorial
Browse in : All > Journals > CVu > 126 (17)
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 December 2000 13:15:40 +00:00 or Sat, 09 December 2000 13:15:40 +00:00

Summary: 

Body: 

At the recent meeting of the C++ Standard's Committees I found myself telling a long time fellow committee member that something he said he would do was unprofessional. First, let me tell you what it was and then let me tell you why I still maintain my view.

During a refreshment break we were discussing the reasons why code is so often buggy. One obvious reason is that code gets shipped before it is ready. I stated that I thought a professional programmer should have enough pride in his/her work to require quality before shipping. John (that was not his name) said that this was impractical and that he would even ship a prototype if his employer told him to do so. My response was that anyone who espoused to be a professional in an engineering discipline would never do such a thing and that they would refuse, not least because of the professional liability for releasing a product that was known to be unfinished.

John said that, while he might agree with me in theory, in practice, he had to feed his family and so he would still follow instructions. I do not know how you feel about this attitude, I know that my immediate response was to say that such an attitude was unprofessional and that the prevalence of such attitudes demonstrates that software development is not yet an engineering discipline.

Sometimes we get too close to a subject and it helps to stand back and look at something similar where we have no emotional investment.

Some of you know that I am a qualified senior RYA sailing instructor. Among other things that used to entitle me to examine people as sailing instructors. I also used to run outdoor pursuits for a small voluntary organisation which relied on those in their late teens to do much of the instruction and supervision (very good for those involved. They were not aware that they were always quietly supervised, and so learned to make responsible decisions).

One of the other adults was a competitive catamaran sailor at international level. I used to arrange that Ken would wander up on some day when the weather was very bad and quite unsuitable for introducing novices to sailing and tell perspective sailing instructors that they were each to pick one of the youngsters who had never sailed before and take them out. Any one who actually did so (in other words took authority's word rather than using their own judgement) failed. I did not, and do not, want instructors of any age whose judgement is either flawed, or who allow others to over-rule them.

On another occasion I was running a large (about 60 children and adults) outdoor pursuits camp in North Wales. One small group (six) of thirteen-year olds was particularly bad at listening to instructions. One day I arranged that two of the junior officers (seventeen-year olds) would grab this group when they returned from normal activities and immediately take them out on a lightweight overnight camping expedition. The youngsters would have no time for argument, but only to get their things together, collect tents and go. Of course they would find it difficult because they had not done the pre-training on lightweight camping. Hopefully this experience would help them see that some of the 'boring' stuff was actually useful. As far as the party of eight knew, they were on their own. The junior officers had been given a route and a destination where they were to camp. Of course they were covertly supervised throughout.

In fact the daytime activities finished later than planned with the result that the group did not reach their planned camp site till after dark. As life was not at risk, only comfort, they were allowed to continue.

When the expedition returned the next day I debriefed the leaders. They were honest about the problems they had had. When I asked them whether they would do the same thing again each said they would not. At least experience had taught them something, but not, to my mind, enough. This lead into a discussion of responsibility. The upshot was that the two teenage leaders decided that their real mistake was not in going at all, but in rigidly sticking to instructions when circumstances changed. What they should have done when sunset approached, was to pick a suitable camp site along the planned route and camp there.

Those are just two examples of how necessary it is for those that are to take responsibility to learn what that means. An understanding of the consequences coupled with the courage to do the right thing are essential ingredients.

It seems to me that it is appropriate that we require a similar sense of responsibility from people who would call themselves engineers. The defence that 'I was following orders' is not sufficient and no one should believe otherwise. If very senior people in software development think it is, what hope has the newcomer to our profession. Not only should you have too much self respect to ship code you know is bad (of course in some circumstances shipping code with known, non fatal, defects might be acceptable - that is a professional judgement call) but you owe it to your professional colleagues to uphold professional standards. Until this is recognised and accepted as the norm in the software development industry, programming will not be an engineering discipline.

Notes: 

More fields may be available via dynamicdata ..