Job security

A software developer reportedly wrote malicious code to ensure job security:

It wasn’t a club but a computer virus that shut down the Whac-A-Mole and more than 400 other games built by Bob’s Space Racers in Holly Hill. The company traced the problem back to computer programmer Marvin Wimberly.

Faced with a pay cut, police believe Wimberly programmed games to fail, ensuring he would be needed and keep making money.

[…]

Each game, after turning on and off a certain number of times, sometimes 50, sometimes 500, would fail. Wimberly would be paid to fix it, and police reports say, he would insert a new virus with a new countdown.

Of course, the big story here isn’t that the malicious action happened, but that it was discovered and traced back to the allegedly deliberate actions of an employee, and that police have been involved.

My guess would be that this type of thing goes on all the time, and is either not noticed or not taken seriously. I suspect it’s mostly not a deliberate sin of comission but a subtle sin of omission: developers don’t refactor, or don’t document, or don’t upgrade their design to integrate with new components. Quite probably they come up with ostensible reasons why it can’t or shouldn’t be done that are sufficiently convincing.

The irony, of course, is that doing a better job should make you more employable, not less. Even when unemployment was at its peak, the companies I’ve been working with have been terribly short of quality developers.

Here are some of factors that I think contribute to this:

  • People end up working in software development who don’t have the necessary interest or aptitude, but carry on with it because giving up would cause them to lose face, or because even a badly-paid software job is better than a great deal of alternatives.
  • Management in companies where software is only a small component of the business don’t necessarily understand the software development process, and as a result are overly deferential to the opinions of developers. Furthermore, they overestimate the cost of replacing an incompetent developer with a competent one, and underestimate the long-term benefit.
  • Bad developers are rewarded too well, and good developers too poorly. The best developers deliver something like 20 times the benefit of the worst developers, but are lucky to get paid twice as much. This blunts the incentive for a mediocre or poor developer to improve themselves, and encourages those at the bottom end of the scale to hang on rather than move to a different career to which they may be more suited.

Leave a Reply

Your email address will not be published. Required fields are marked *