The Only Good Hero is a Sandwich

As I wrote in my earlier entry on heroism, there is a vein of hero-worship in the software industry that runs deep.  If I were a psychiatrist, I suspect that it's a side-effect of the geek collective unconsciousness and the usual high-school jocks-vs-geeks rivalry - it's our chance to save the day, instead of just watching some sports person do it.

Over the past few months I've see this topic rise up in the blogosphere, so I will paddle out and ride that wave as far as I can (who says ninja can't surf?)

It could also be that I was just pulled into a half-day of weekend work for no good reason.  More on that anon.

Here's one right on point, detailing how heroism hurts an organization.  I especially like how it gets related to the customer's viewpoint, something that I tend to dwell less on, being further away than some.

Skorks has this take on it, more in line with my personal view, and making a point of the perverse pride we  developers can have in the terrible conditions we sometime work under.  He also takes on the converse issue, that of the deprecation of those who get all the work done on time and under budget.  This is another one that I ran into personally, where one company was giving out an award and give it 3 months running to the developer who was working late fixing broken stuff, and never once to the developers who got all their stuff done in the 9-5 hours.

And then there is the institutional schizophrenia of places that do not treat the developers like professionals - because, after all, if the programmers aren't here late, they're not really working, right? And if they change their minds about how long it will take, they're just lazy.

But all is not lost - there are signs that at least some of the people in management positions in the industry are seeing the light.


Now, as to my weekend spoiler - it's one of those last items - an artificial deadline, set by a manager based on a preliminary estimate, but set in stone because it was somehow ennobled by the company's scheduling process.

So how does a ninja cope with this?

There are the time-honored suggestions - first, take whatever estimate you can some up with, and double it.  Chances are, you are as optimistic as I am, and your guesses as to how quickly you can code something up are forgetting the little things that get in the way - meetings, overnight build failures, field issues that only you can fix, corporate mandatory training, etc.  We also tend to think we will get a full 8 hours of coding a day. 

Secondly, start tracking your estimates to get an idea of how good you really are, and record how detailed your estimate was, how much external interference you got.  If you can get statistics on how little time you can really spend on the code, you can use it as ammunition the next time your manager asks you if you can pull the completion date in a week, because the Senior VP is visiting that week and he;d like to see a demo.

---