Monday, February 22, 2010

De-Motivation in Bugs.




So I recently read this article on Motivation vs. De-motivation from the Harvard Business school:

And since I have had a few days to digest it, it has started to sink in. Perhaps I don't have any issues motivating myself, but rather issues de-motivating myself. Specifically I started to apply these thoughts to work, where I am a "Second Class Citizen" simply because I am on the dreaded Bug Fix team (or so my manager says). This my friends is where one of the major problem with corporate software development lies.

So let me first explain a phenomenon that I have seen pop up all too frequently. Software is written, at a pace that would lap an Olympian. And it works!!! Huzzah! But the old saying goes Fast, Cheap, and Good choose two. They definitely chose Fast, and while it wasn't Cheap per say it also didn't have money poured into it by the truck load (maybe a few buckets here and there to keep it afloat). So what your left with is a working but not entirely good piece of software.

Now for the pieces of the puzzle that your not as familiar with. So there is a team of developers who just coded like they're lives depended on it and made your product into a viable solution for your company, well they deserve raises and promotions!!! Something anything, give these guys a bone! Some will even be managers. Even if they don't want to be, who's really gonna say no to the $$$ that comes with the deal? Well it matters not because they are generally not the ones with the de-motivation issues. They have established that they are motivated and now they get to do what they want to. But yeah now that they are not the core go to, to get stuff done people well geez better hire some new devs to fill in that gap!

Management1: Where should they start working?
Management2:Well since everything is sorta working, lets go ahead and...
Management1:OH %#@^&!! The just {Enter Feature Name Here} stopped working!!
Management2:Thats pretty much all our app does! We need that fixed yesterday!
...
Management1:Well who made it?
Management2:Dev X+ made it, but he's working on that new project we're steam rolling along, so we can't have him fix it.
Management1:Ok, well tell one of the new guys to fix it.

And the new guys de-motivation begins...

Personally I think that fixing bugs in someone else code is one of the trickiest things to do as a software developer, and also one the things that is least gone over in any education or book (I would be happy to be corrected on this). The real problem with this situation though is that the business person who doesn't understand code, see this as Dev X+ being too important to fix his own old mistake, means that whoever the lowly dev is that does get to fix his mistake, must not be as smart or worth as much money or is just generally worth, less.

Management2:Well the new guy did fix the problem with {Enter Feature Name Here} and boy did he do it quickly, well while he was doing that 3 more issues pop'd up lets hand them to him to fix.
Management3:Cool, I have a couple problems that have come in from Customer Support as well can we get him to fix those too?
Management2:I don't know, lets assign them all to him and see what happens.

Well next thing the new guy knows he has 3-4 people giving him work to do, and no matter how much he gets done there will still be more to do than when he started. Add a office culture that deems his duties the lowest of the low, and boy! I'm sure in a few months he's just hoppin outta bed in the morning ready to get to work and feel productive! (for those of you lacking a sense of textual sarcasm... that was sarcastic).

IMHO it is very de-motivating when you are not able to put a dent in your work load, no matter how much you work at it, and also when the people who made the problems you are fixing are at all conceited about helping fixing them (let alone fixing them themselves). These two factors alone can sap the motivation out off all but the most die hard enthusiast.

Next post "Whats this supposed to do again??: The De-motivation of poorly defined goals"