Before you start criticizing that programmer for all the bugs you're finding in your latest project, read this week's column by Elisabeth Hendrickson. She advises us all to try to understand the other person's situation before we resort to blaming.
Over the last several days, I've encountered numerous instances of programmer bashing. I've heard nontechnical managers complaining about the "idiot programmers" in their shop, had test managers claim the programmers were "user hostile," and most recently read a comment on a Web site calling for legal action against individual programmers who introduce security holes. In each case, it seemed that the commenter intended the comment to be humorous. At least for me, the humor is wearing thin. An attitude of blame lay just behind the humor: "The programmers make the bugs, blame them for poor quality!"
Every time I hear a comment painting large groups of programmers with the same brush, I think of programmers I've known who don't deserve that treatment.
Mikey, the youngest programmer in an Internet tools company, prided himself on producing 100 percent reliable, robust code. He had a standing offer: If you found a bug he didn't know about in his code, he'd buy you lunch. He didn't have to buy many lunches.
Ward, an old-timer who'd learned to program on punch cards, had a patient and calm demeanor no matter how hairy the project. He took the time to do things right, even when that meant standing up to a manager who wanted Ward to cut corners. His approach paid off. By the time he delivered his code to test, there were few bugs. Those that did appear were minor oversights or unpredictable integration issues. Further, the time he spent drafting comprehensive specifications made it easy to design the tests and write the documentation.
Karen specialized in internal tools. If you could envision it, she could build it and build it quickly. She was so speedy, she often had it built within a few hours after you said, "wouldn't it be cool if..." Generous with her knowledge, she was a patient if sometimes demanding mentor.
In fact, the more I think of all the programmers I've ever worked with, I can remember only a bare handful that were incompetent or even remotely deserving of ridicule. The vast majority of programmers are diligent, capable folk. They truly care about the quality of their work and want the software they produce to be useful. They are more interested in producing a good product than playing CYA games. They work hard to make sure they are implementing the right features and writing solid code.
I have, however, seen a few situations where programmers seemed to lose their focus on the customer. Betty, an otherwise quality-conscious programmer, surprised me by insisting we should ship software that was causing intermittent blue screens on Windows machines. She pointed out that the blue screens were rare, couldn't be debugged because they couldn't be reproduced, and couldn't possibly be caused directly by her code. I was shocked. I insisted, in a nastier tone of voice than I intended, that we weren't going to ship anything that caused blue screens. Betty and I ended up in a screaming fight-one of the few in my career-and it took a VP to force both of us to back down long enough to talk about the real problems.
If I'd stayed calm just a little longer, I would have realized how much pressure Betty was under. Her bonus, and quite possibly her career with the company, rested on her doing well with this project. It was a high profile, quick turnaround project and had been handed to her because of her previous track record for releasing well-received products within tight timeframes. Betty had a reputation to protect and difficult expectations to meet.
Unfortunately for Betty, she