Sunday, November 23, 2008

Professionalism

I thought this would be a good starting point for my blog.

I am often surprised when I meet software consultants on client sites by the lack of professionalism. I suspect that it's not that they don't care about professionalism or that they don't know what it means, but rather it's more likely that they haven't given it much thought. Now I realize that if you live in a glass house, you shouldn't throw stones, and I'm not saying that this applies to all the people I've worked with, I have had the opportunity to work with many individuals who exemplify professionalism. In fact, some have helped me to formulate my current opinion on the subject. However, I've often heard people who are not consultants question the value of consultants, and I take offense at that because I strive for a level of professionalism that I feel would silent the critics. My goal here is not to criticize but to correct.

I feel that there are five main pillars upon which professionalism is built. In no particular order, they are; Ethics, Accountability, Responsibility, Quality, and Communication.

Ethics. When I was working at Capra, all our consultants were required to accept and sign our Code of Ethics. Don't agree with it, fine, you just won't work on our projects. None of this is earth shattering stuff, but it seems that every time I read it I wonder how many people have actually sat down and thought about what they consider acceptable behaviour. I'm afraid that unless one takes the time to write it out, one is left to make those judgments at the spur of the moment, and then it's too easy to just go with the flow. Ask yourself, when is the last time you "stopped the clock" when what started out as a business conversation turned to a personal nature like sports or movies? Or how about surfing the internet while you're at work? Have you ever walked up to someone's desk and noticed that they were reading slashdot or digg? Now in the spur of the moment, one could argue (as many have) that those are technical sites, and they improve my ability to do my job. My reply to that is that though there may be some value in those sites, the amount of useless drivel in the comments reduces them to an entertainment.

Accountability. "It's not my job!" "It's not my fault!" These are things that you typically only hear from people who are being accused. If one acts professionally, then one voluntarily takes the blame when it's appropriate. Such an individual seldom has to use the above phrases because those he works with know that if it was his job, or his fault, he would have said so already.

Responsibility. This one follows on accountability. Accepting the blame is only part of the problem. The other part is fixing your mistakes... at your own cost. Oooh, I think I just lost half of you! "But what about my paycheque?" My advise to you would be to log your time and write it off as an education expense, but you actually have to learn from it. I've had this discussion many times with a colleague of mine, and I don't see it changing any time soon. If you hire a painter to come into your house and paint your living room, and two weeks later the paint starts to peel off the walls, you would be correct to expect him to come back and not just touch it up, but sand the whole thing down, prime the walls, and paint it again... at his cost (including materials). The sad thing is that I doubt you will ever see this level of responsibility in the software industry. And I think that the reason is that in order to know what is a bug and what is a feature enhancement, one has to have very thoroughly defined requirements identified up front. And though many people do get requirements up front, they fail to accurately identify the knock on effects of change requests, and so when a bug is found it's very difficult to know if it is the result of the original work or some change. Until such a time as we are able to figure out piece work in our industry, let's be responsible and honestly fix our bugs for free. I expect that you know when a bug is really your fault and when it's not. Own your work, and no one will be able to acuse you of just keeping a chair warm.

Quality. How many times have you heard someone say "I don't have time to write unit tests"? My answer is always, if you don't have time to do it right, when will you ever have time to do it over again? If someone asks me how long it will take me to do a job, my estimate includes unit testing, period. If they come back to me and say that my estimate is too long, and that someone else can do it faster, I will inform them of the breakdown in the time, but I will not do the job without the unit testing. If they don't like my estimate, they are free to go with the other consultant... but if they call me in to fix the work of the other consultant, I will have to do the unit tests that the other guy didn't do before I can start any of the current work. The goal is 100% code coverage, but this does not mean writing a unit test for every line of code. (More on unit testing in some future post.)
Another line I've often heard is: "It's not the way I would have done it, but the client told me to do it this way". Go back to our painter example, if you told him to paint your room without priming it, many people would say it's your fault that the paint is now peeling. And yes, you should take part of the blame. However, the painter should have walked away from the job and said that he could not in good conscience do the job because his experience tells him it is going to peel. You would be surprised how convincing it is for most clients when they see that a contractor is prepared to walk away from a paycheque because he does not want to do shoddy work. (Before you painters start emailing me, it's just an example. I know that often you don't need primer.)

Communication. This is one of my pet peeves, and it really has two parts. The first is prompt alerting of problems, and the second is the quality of the written word.
It absolutely drives me crazy when I see someone coding feverishly. It's almost invariably because the task was more complicated than expected, or they ran into some sort of problem with the environment. The professional developer communicates with the project manager immediately as soon as a risk to the delivery date is encountered, and the onus is then on the project manager to "manage" the expectations of the client. This doesn't give the developer carte blanche to put his feet up on the desk and read slashdot, but it does mean that the developer does not have to panic about the date. A rushed job will always be full of bugs. Better to reduce the features than to try to force everything in when it's not ready.
The second part to communication is professionalism in the written (and spoken) word. The popularity of text messaging on cellular phones has started to spill into business communication, and as far as I'm concerned, there is no place for it. Now before you start to think that I'm some old man chasing the kids off my yard, let me tell you I also use abbreviations when I am text messaging, because hitting the same key three or four times to get one letter out drives me nuts. But when I am sending an email from my phone, I do what it takes to make full sentences... including punctuation and capitalization. I had a colleague once come to me raving mad because he felt he was not being treated as a professional. He showed me a print out of his email exchange with the other party, and it was filled with text messaging abbreviations like "ur" instead or "your", "imo" instead of "in my opinion", etc. Furthermore, none of his emails had a salutation or a signature. After reading it, I told him "I'm sorry to say this, but I wouldn't respect the sender of these emails either". Now I'm not claiming to use perfect punctuation or grammar, and quite often I make spelling mistakes, but this stuff is like speaking to someone with a tongue piercing. It's just simply not professional. You want to have a piece of hardware in your mouth while you are out with your friends, great, go nuts, but pull the thing out when you are at work. Same with the text messaging stuff, use it between friends, sure... just keep it out of the office!

Wow, I really do sound like that old man yelling at the kids in the front yard. It's simple, if you want to work with me on one of my projects, better be ready to work professionally. If you want the respect that I get from my clients, consider these some starting tips. I've gone much longer on this than I planned, and I might edit it later to shorten it some. My hope is that some people might read this and that I might infect others with professionalism.

</rant>



No comments:

Post a Comment