Developers versus PR

This post is more than 16 years old.

Posted at 20:45 on 02 July 2007

Robert Scoble mentioned a few days back that large software companies don’t like their developers talking to the press. This, he says, is because their PR departments know fine that we developers (a) don’t tend to be all that good at PR kinds of things, and (b) have a tendency to tell "the unvarnished truth".

I sometimes wonder if this is a bit self-perpetuating, somehow. That kind of thing means that your average enterprisey geek doesn't get to see how PR operates, so they haven’t a clue. In a small company, it’s different. When you are sitting cheek by jowl with the PR department, you get a first hand experience of what not to say to the clients. You soon learn, for example, that expressing a lack of confidence in your own products is generally a bad move.

However, I think a lot of it is down to differences in perception. When you are a sales guy, your job is to get the clients to sign on the dotted line. You tend to make bold statements that instil confidence in the client. You don’t tend to worry if you’re promising them a holodeck, a dozen tricorders and a warp drive. Making sure that it actually can get you to Alpha Centauri in one piece in less than a week is Not Your Problem.

We developers tend to be much more cautious, however. We see what goes on underneath the covers: the stack of outstanding issues in the bug tracker, the multiple copy-and-paste jobs of four hundred line functions by the previous developer, and the fact that one of the other developers on the project is called Paula Bean. When you’re staring that in the face every day, the glowing statements by the PR guys start to sound like barefaced lies.

The other thing, however, is that just because a developer thinks that the code is rubbish doesn't mean that it actually is. We tend to be an opinionated bunch, and we usually have pretty strong views on things such as what language to use, stored procedures versus dynamic SQL, or even tabs versus spaces. We tend to get into Religious Wars about this kind of things, and some developers even regard people who take an opposing stance to them as total idiots.

The fact of the matter is that the best developers are hopeless perfectionists for whom "good enough" is never good enough. We encounter so many bugs that we worry somewhat in case a disastrous one will slip through the net. Usually our worries are unfounded, of course -- that’s why we have quality assurance guys -- but we don’t want to be the ones that get sued if everything does hit the fan.

The time that you really need to worry is if a developer tells you, "There are no bugs in our software." Every developer with more than zero experience knows that this is never true, and if he actually says it, it's an indication that either (a) he is telling a bare-faced lie, or (b) his testing is woefully inadequate. (I speak from experience here. A while ago I got an e-mail from the lead developer of a commercial software package that said just that. The program was so buggy that it was almost unusable.)