If we're not going to talk about functions and objects and squiggly little lines of incomprehensible text, then what on earth are we here for? What could possibly be more important to a developer than the details of writing code? The answer is both obvious and elusive in the same breath. The most important thing to programmers everywhere is not writing code, but rather delivering quality software.
Did you just stop, shake your head and read that last sentence again? You're not alone. Almost universally, good programmers reflexively equate writing code with delivering software, as if they were one and the same thing. They are not. In fact, it is this very view that is largely responsible for release disasters worldwide.
If you don't know what a release disaster is, you've led a charmed life. Take two donuts out of petty cash and go back to what you were doing. The rest of us are all too familiar with the details of good releases gone bad, including arbitrary deadlines, endless overtime, high stress levels, short tempers and monitors flying out of fifth floor windows, all for a product that gets shipped long before it's ready due to market pressures. When your software hits the streets with more bugs than a cheap motel and less stable than a maintenance programmer who hasn't slept in a week, are the technical details of coding really the guilty party? Not likely. I can assure you, some of the worst software releases I've seen were the product of absolutely brilliant technical minds. Let me present that thought once more, for emphasis. Poor quality software releases are almost never due to a lack of technical skills.
So, if the project you're working on is greeted by the user community with those two immortal words dreaded by programmers everywhere ("it sucks!"), then who's the culprit if not the code? The programmers, of course. Hey, you didn't think you were going to get off the hook that easily, did you?
Comments