Title: Your Letters - The Editor's Replies

Dear Francis,

I read your leader on Professionalism in the latest C Vu (12.6) and it has prompted me to this reply. There is something about the way you put over Professionalism and Responsibility that I am uncomfortable with. Maybe you have done this deliberately to stimulate a debate. If so, I hope that people who can marshal a better argument than me join in. Rather than wait for others to comment in the next C Vu I am giving you a response even though I am not entirely happy that I have completely identified my concerns. I am happy for you to publish this as part of a debate in C Vu or for you to reply to me personally.

Why am I concerned? I am not sure but I think it revolves around the following three points

Now I am going to ramble on with some background to these three points, starting with why I believe that the situation is more complex than just the good programmer and the evil boss.

Personally, I am on the other side of this story - I am not a programmer but a consultant. I would expect any work that I commission from a programmer to pass through at least 3 stages of testing before being put into actual use. Obviously this varies with methodology and size of project but I expect to see program testing, integration testing and user acceptance testing. A programmer would be responsible for the first but not directly for either of the other two. If a programmer tells me that a program "works" but that some technical part, like the database error handling, is untested I would certainly instruct him/her to release the program to integration testing whilst he/she continues testing. If the programme covers several functions and I am told that some work and some do not, I will take a view on whether sufficient works for the program to be released to integration testing. So here I am, the evil boss, instructing a programmer to ship code that is known to be untested/unworking. And I do this because on the commercial projects where I work I have constraints of time and money. Generally it is more time efficient to complete program testing in parallel with integration testing rather than have serial processes. I could argue that I am not that great a villain, as the code is not being shipped to production use. However, once I have instructed the programmer to release code to the next stage of testing the code is essentially out of his/her control. The code can be released to user acceptance testing without their knowledge and/or involvement. Later it can be shipped to production without my agreement, knowledge or involvement - as I have project management above me who can give the necessary instructions without consultation.

So, in the sort of environments where I work, there is no sharp divide between a programmer having control over code and then the code being shipped into actual use. Instead there is some form of staged loss of control - code is released on the understanding that further testing will continue, that certain functions do not work, that changes will be made. At what point should the programmer make a stand? At what point can I justifiably say (preferably not as bluntly as this) "that is my decision, not yours" and so I carry the professionalism issue? I am also concerned about the sanction - "work professionally or I quit". Will it be that after 10 professional programmers have quit the employer finds that he manages quite adequately with a staff of un-professional programmers? How are we, a professional body, going to increase the level of professionalism in our industry if whenever we find something we do not like the answer is to threaten the big sanction? How is your colleague on the standards committee ever going to dig into the organisation and improve professionalism there if he has left? And we know that it is so, so difficult to improve professionalism up the hierarchy - you have to move into a position of authority and work from there. My belief is that we should, as professionals, avoid getting into a situation where we threaten the big sanction. It is so like a parent telling a child "behave or I will smack you" - the battle is lost already.

And so (the hard part) what advice has the ACCU got for its members? Should we encourage programmers to give pessimistic reports on program testing until the code is 100% OK? There are lots of problems with this approach, not least the little lie to save the bigger lie. Or what else can we do to support members caught between the proverbial rock and hard place? This is where I would particularly like to hear the advice from other ACCU members.

regards

Richard Wheeler

I agree with almost everything you write, except that you have placed a spin on what I wrote that was not there. I never used the word 'quit' nor did I suggest that anyone should threaten to do so. Nonetheless the attitude of mind that accepts minimum quality is not, at least for me, professional. We should be striving to deliver the best we can, considering the constraints under which we work. That includes limiting work to a reasonable number of hours per week - and I also consider regularly working excessive hours as unprofessional. The employee who continually works late is the one who should be investigated, not the one who usually leaves on time.