QA in a team of peers
I am developing an application with four other contract developers. The application is made up of a few different components utilizing VB, SQL Server and an Excel reporting component. One of the team will not adhere to the standards that the rest of us hold near and dear.
This person has the least experience within the team.
For example, he refused to remove hard coded directory paths from his code.
In the end I did it myself, upsetting him even further.
He will now not participate in code reviews.
We have cajoled, reasoned, explained and hand held beyond what is reasonable.
I lent him my copy of code complete with the section on code reviews bookmarked.
We cannot get rid of this person before the end of the project, which will be in January 2002.
The possibilities are:
1) Let him do whatever he wants, obviously we keep the difficult/important stuff away from him.
2) Let him do nothing and carry his load.
3) Keep fixing his code for him.
What do you think is the best approach in this situation?
I want to keep the work environment as positive as possible. i.e abuse and overt criticism are not possible :-)
Saturday, November 17, 2001
Frankly, none of your three options will help you meet your objective of "keeping the work environment as positive as possible (i.e abuse and overt criticism are not possible)."
All three send a strong message "We do not trust you or your work" to your co-worker. Your attitude (we can't get rid of him until ...) and actions (changing his code .. just think for a moment how you'd feel if somebody changed your code) amplify this message. This will only create a very negative working environment.
Somebody much wiser than I said "You cannot change other people, you can only change yourself". You can however create an environment that will encourage someone to change. If you genuinely desire to retain a good working environment, you will need to do so.
As a team you clearly have not reached a consensus on your approach, the "mutually shared vision" of Peter Senge's approach. It is very late to start to build one but without this mutually shared vision, your conflict will continue to rage.
You also need to confront this issue with you co-worker. At the moment it seems that you are simply confronting the co-worker. What seems to be needed is for the team to clearly explain your personal needs of the QA process (not just the technical reasons) and to seek which of your co-worker's needs are causing his behaviour. This will probably have nothing to do with QA. Even to uncover this will require a higher degree of empathy towards the co-worker from the team.
Of course, it is not always possible to resolve such a conflict. Then the only alternative is to replace the co-worker continuing with the current situation, even adopting one of your three options, will damage the project.
Peter WA Wood, IT Matters
Saturday, November 17, 2001
Well, you can dislike working with someone, but if it would be really painful to carry the burden of not letting him contribute, then your management job is working with "unreliable components." It won't be a cakewalk, but you can't replace him. If your clients hired him, then they have to accept certain tradeoffs in the software.
Maybe you can find some gruntwork for him to do, that he'll probably enjoy anyway. A programmer who does not lmpw what's wrong with hardcoding dirnames will not produce the best software in the world. But if you specify the API he must code to well enough, you can minimize the impact of error well enough that you can treat his work as a library you happen to have the source of.
Saturday, November 17, 2001
This is a case of what McCarthy calls "flipping the bozo bit" ( http://firstname.lastname@example.org/msg00628.html ). Frankly, I'm one who believes the bozo bit is a very useful evolutionary adaption that goes all the way back to when poor Og was excluded from hunting-and-gathering trips because he picked poison berries and scared all the game away. We hire only great people because we realize that bozos do exist and we're doing ourselves a disservice by hiring them.
Unfortunately, the bozo bit does get set on many people who don't deserve it, and that's a real problem. I don't know if your coworker is the sort that actually deserves it, or is merely inexperienced. Hard-coding directory names actually sounds like a small thing, and if you spend an hour squabbling over something that may only save you 30 minutes of time in the long run, it's better just to pick your battles. Because what's really going on here is just a battle of egos. Geeks have this fantastic ability to disregard completely common-sense suggestions when it comes down to a matter of ego and personal pride. Trust me. I've been on that side of the fence many times myself. =-) You might get a lot further if you just simply asked him to make a code change and let it go at that, instead of demanding and leaning and arguing and insisting him make a change.
Another important thing to note: code reviews are essential, but you can't review someone's code against their will. It just doesn't work. Nobody likes a code Nazi. In this case you have to lead by example, showing a willingness to have other people critique your code, before you can expect others to be equally open with their own code. Invite your coworker to your reviews and encourage him to just flame your code. Log his observations patiently; show him how you expect people to take criticism without being defensive.
Also in the meantime, you might want to remedy his inexperience by putting him on fire-fighting details that wouldn't have happened if the original coder remembered to indent properly or comment liberally or error-check input values or remove hard-coded values. Put him on QA. The upside is that you keep him productively busy while keeping him away from writing new code. But also, eventually after he changes the nth hard-coded string he might come to you bitching about how stupid programmers are who hard-code directory paths.
Monday, November 19, 2001
Fog Creek Home