Daryl is a programmer. He works at a small ISV, writing web based applications and online games. Daryl is also a very good communicator and has a fair amount of graphic design skills in Photoshop. Because of his communication skills Daryl’s boss entrusts him with writing the specs of any new project. He’s doing a fairly good job at it too, and is looking forward to a good review at the end of the year.

But there’s a glitch.

Because it’s a wee little company, Daryl’s boss has very little leverage before his much larger clients and strategic partners. Often, they have to take up boring maintenance or debugging tasks on a codebase that only the most insane minds would be capable of writing. Life sucks. But they hang on with a brave face. Daryl keeps at it because he knows his boss is really nice at heart and understands that he doesn’t have much say in the matter. His boss doesn’t mind because these projects keep the cash inflow coming, without which he’d never be able to hand out that hefty paycheck to Daryl at the end of the month.

Now one fine day his boss lands up with a really exciting project to develop a game for a large publisher. Daryl is really excited about the entire affair and dives into it with gusto. Being a sane, level headed developer, he begins with the specifications. Whirrrrrr…buzzzzz…clank…clank…bling! Dust flies, sparks shoot and the racket is just about to get on everyone’s nerves when Daryl stops and hands out a pristine 20 page document in Adobe PDF format. It’s a gem of a specification and everyone’s really excited about it.

His boss negotiates the terms, the schedule is fixed (of course Daryl has a say in what will be developed when), and work begins.

Daryl is a little worried because he’s using a new technology called Gleam, that’s supposed to be the hottest thing in online gaming since GUI’s. But because its a fairly popular technology, he’s sure to find a lot of help from forums and websites. And he begins coding.

On day one things are fine. On day two, Daryl’s boss comes in looking very harried. They’ve just been arm-twisted into working on a tiny maintenance project by one of their partners, Extravagance Software. Okkkkk…Daryl says to himself. I think I’ll put this game that I’m working on aside for a bit and quickly finish off this maintenance task. It’ll mean a day lost, but I’ll catch up with it by putting in a weekend. Or so he thinks.

The day ends and he somehow manages to patch the code from hell that he’s had to maintain. Some of the fixes work but there are others where things are not so good. And more bugs come up during further QA. Daryl, blissfully unaware about this, comes in to work the next day and is just about to get back to his game when the manager from Extravagance shows up outside his office. He’s tearing his hair out, and screaming obscenities at the client, his ‘stupid’ coders, and pleads before Daryl on bended knee. Daryl looks at his boss, who shrugs back at him. So Daryl puts his work aside again and spends another day fixing someone else’s code instead of writing his own.

…and the next day, the story repeats.

Daryl is about to lose his patience, but feels he owes his company enough commitment to do what is required for the moment rather than crib about how boring a maintenance task is. But how far should he go? Does he have to continue slaving over this at the cost of his own project? Does his boss have to continue to let him do that?

I don’t know. I’ve spent enough time at companies, both small and large, to have been on both sides of this very real issue. Larger organisations often have enough financial and strategic muscle to control the smaller service vendors. Smaller outfits have often enough been in dire straits to have to constantly worry about keeping up the cash inflow. A level headed developer will usually end up unscathed through his entire match, and maybe even learn to accept it as a way of life. But if somebody can find a solution, it’ll mean a breath of fresh air for ISV’s and encourage more people to start one.