As programmers and system designers, we want our time to be spent well and our products to be well received. Nobody likes to spend weeks of their life coding a system that ends up being hated and unused. But hey, you were likely paid for that work, so what does it matter? Well, unless you reflect on what exactly caused that scenario, the situation will probably repeat itself in the next project or another one down the road.
Of course, maybe it wasn’t directly your fault. Maybe you were constantly distracted by that guy who screams into his phone a few cubicles over. Maybe your boss constantly forgets his passwords and thought the best person to bother was you. Maybe the other developers decided that the coding standards were beneath them and made peer reviews a living nightmare. Or maybe the software specification just sucked straight from the beginning. Sometimes these things happen and become unavoidable or at least difficult to avoid. But never, ever, let a product suffer as a result of not delivering to the specification; no matter how bad it sucks.
“But it was just that awful! There was no punctuation, and the writer decided to write the entire thing in Ye Olde English.” you shout. OK, wow, that’s pretty bad. But why weren’t these things brought up during the specification review and sign-off? I guess someone up top thought it was well written and chock full of good ideas. If it somehow managed to pass through the stakeholders and into your hands, then there’s not much you can do except leave the company or do your best to implement the funny jokes generator that slipped in from someone in management at the last minute.
Now, that doesn’t mean the specification can’t be improved. You can certainly bring things to the stakeholders’ attention for post-sign-off review. Perhaps you don’t know the subtle distinction between thou and thee which seems to be sprinkled everywhere in Ye Olde Specification. This approach to specification review is quite common, because things will inevitably surface during development that you didn’t expect. This path leads to happiness and sanity.
But sometimes, we programmers get that creative spark, that hint of artistic genius, our Van Gogh moment. Ignore it. Don’t let your imagination get the better of what you should actually be doing which is delivering to the specification. I’ve had the displeasure of working with someone (we’ll call him Rembrandt) who constantly wasted time implementing features that no one asked for. And you know what, some of the features were really awesome. Rembrandt had some genuinely good ideas. Rembrandt also caused the ship dates to constantly slip because he was never finished with the agreed upon tasks.
Therein lies the lesson. Don’t create features that aren’t explicitly stated in the specification. I know it’s hard to ignore that nagging voice in your head that says, “It will only take a little more time to add this other feature!” In reality, it probably wouldn’t take much time to add useful little features.… Read more