Click here to Skip to main content
Click here to Skip to main content

Pro Developer: Delivering Quality Software

By , 1 Sep 2002
Rate this:
Please Sign up or sign in to vote.
Pro Developer is a monthly article series devoted to issues that affect developer's lives in the workplace. Each installment will touch on topics that are important, but often ignored by many developers. The first installment, 'Optimize your View', discusses the need for developers to look beyond the coding aspects of the job and shows the direction of articles to come.

Optimize Your View

For anyone who spends a lot of time writing user interface code, optimizing the view immediately conjures up images of windows, clever little UI gadgets, usability issues and a long string of design meetings with excitable and over-caffeinated programmers. The fact that these little get togethers may very well involve airborne white board erasers traveling with great velocity and purpose is just another testament to the passionate importance we place on how our software is presented to our customers. Indeed, the portal through which the user peers into the depths of our code often seems to define the software itself, at least in the eye of the beholder. Consequently, we acknowledge that user interface issues are not just a matter of putting on a pretty face, but in fact define the boundaries within which our users will operate. Put a clunky view on a good piece of software and you end up with a clunky piece of, well, software.

However, those of you who have already fired up your programmer's editor and called in your order for a pepperoni pizza in anticipation of yet another exciting session of coding are probably getting a little ahead of the game. We're not here to talk about the bits and bytes of coding. We're here to talk about something much more important - your future as a professional software developer. So, you won't be needing that programmer's editor for the moment. The pizza's probably still a good idea, though. Some traditions should never be changed.

Setting Priorities

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?

The Usual Suspects

I'm beginning to see some glazed eyes in the back of the room. If bad releases aren't caused by poor technical skills, then how can it be the fault of the programmers? Well, in fact, we're going to invoke a little pretzel logic here. Not the straight, matchstick sized ones that are also good for stirring your drink, but those twisty, winding type pretzels that take a lot of turns but always end up right back where they started. We'll start by listing rounding up all the usual suspects, but trust me, in the end it's all going to come home once more to rest right in our own laptop filled little laps. Pretzels are like that.

In fact, many of the veterans here have already made a list of the parties responsible for screwing up a perfectly good project, and have even made suggestions regarding exactly which wall they should be placed against when the revolution comes. Some of the more seasoned among you may have even suggested that the lawyers must wait their turn, or use another wall.

Who are these villains, these people powerful enough to override the capabilities of even the most brilliant coder? Marketing and management are certainly the first to come to mind, often known as Weasels and Suits when programmers are hanging out by the cappuccino machine late at night. When turned loose on an unsuspecting software development team, the results inevitably include vague and shifting requirements, arbitrary deadlines declared with no concept of the technical realities, scope creep, crisis driven management, complete lack of a professional testing department and in the end, software that was released long before it should have been.

It's Not My Job

What's that you say? I've just clearly proven that it's not your fault? Nice try. And pass me a pretzel, will you? Projects fail for an unbelievably simple reason. Extremely intelligent and otherwise talented programmers time and again make the naïve assumption that if it's not about the code, it's not their job. In modern air to air combat, a jet fighter pilot who finds himself close enough to his opponent to fight it out with machine guns has already missed critical opportunities to solve the problem from a safe distance with long range missiles. And so it is with programmers. If you find yourself in Overtime City with a guaranteed release disaster right around the corner, you screwed up long before then by failing to control your situation before it controlled you. Ouch. Can I say that? Well, maybe I should at least have offered you a pretzel first.

Your view of the software development process dictates what you do, and do not do, in the course of your work week. If you believe that everything beyond coding is "not my job", then you and your project will without question fall prey to the strong and illogical forces that sweep through the corporate world. However, the follies of marketing and management can both be minimized by the savvy programmer. For every bone headed thing that these rocket scientists can throw at us, there is a counter. Manage the problems early enough in the game, and your release disaster instead becomes a release party. They'll probably even spring for the pizza.

The Road Ahead

You don't have to have an MBA or be a sales weasel to effectively manage these problems. You just have to expand your view of the software development process to include anything that might effect your release, and do what's necessary to protect the code you've worked so hard to create. Granted, this isn't always as sexy as writing a flashy UI in the cool language of the day, but when it's 4 AM, you haven't slept in 3 days, and poor management decisions all but insure that tomorrow your product will ship in less than perfect shape, nothing's sexy.

It's time for programmers to regain control of the software development process. Learning sneaky and not so sneaky tricks to deal with all the non-coding issues that threaten our programs, our free time and our sanity is what we'll be doing in the months ahead. Step by step, issue by issue, we'll look into ways of seeing disaster before it strikes and taking preemptive steps. The end result will be more time doing what you really love - writing cool code that becomes the next Killer App. And isn't that really what you signed up for when you chose this profession?

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Christopher Duncan
Founder Practical Strategy Consulting
United States United States
Along with being a professional geek, Christopher is a musician, director and author of The Career Programmer and Unite the Tribes.
 
His latest show is a comedy web series called Talking Head Games.
 
Any resemblance between his personal appearance and that of certain small, hairless canines is purely coincidental.
Follow on   Twitter

Comments and Discussions

 
GeneralStill making my day... PinmemberAlberto Gattegno14-Oct-02 22:16 
GeneralRe: Still making my day... PinmemberChristopher Duncan15-Oct-02 1:18 
Generalan interesting lesson about quitting Pinmemberdavid ewan7-Oct-02 6:56 
GeneralRe: an interesting lesson about quitting PinmemberChristopher Duncan8-Oct-02 2:14 
GeneralOptimize your view PinsussAnonymous22-Sep-02 11:36 
GeneralYou have been noted PinsitebuilderPaul Watson14-Sep-02 3:36 
GeneralRe: You have been noted PinmemberChristopher Duncan14-Sep-02 8:36 
GeneralBrilliant idea PinmemberDylan Kenneally3-Sep-02 2:02 
GeneralRe: Brilliant idea PinmemberChristopher Duncan3-Sep-02 2:32 
QuestionBetter strategy? PinmemberGeorge2-Sep-02 22:37 
Great article, however there is a better strategy - quit when it's getting too annoying or cumbersome!
 
Managers are paid for managing the projects, developers are paid for developing it. If the manager is incompetent and heads on for release disaster then there is no place for me in that company.
 
Why would I want to play all those stupid games when I can just go to another place, and repeat the procedure as long as I find the place that is managed properly?
 
Everybody in the company has it's place and role. The role of developer is to develop, and manager to manage. There is no point to try to "outsmart management" - if they suck you should just quit. Simple and effective.
 
No sleep for days?! Overtime?! You got to be kidding me! The only way I will do any overtime is when they pay extra and cover my transport back home and my dinner. Otherwise - bye bye.
 
I have not the need to expand my view - it's not my job. Really. There are people that are paid to see the big picture and expand the view - they can come and ask if the deadlines are realistic and features are within reach. If they don't - they are responsible for failing the deadline. Turn the view around - why doesn't management get a C++ course and try to understand the development process? For the same reason I don't want to know about management - I am not interested in it.
 
It is sometimes happening that develoepr is blamed for the missed deadlines, but if you are in such a place you have one more reason to quit. Don't allow them to place the blame on you, if you smell trouble just leave the game.

AnswerRe: Better strategy? PinsitebuilderPaul Watson2-Sep-02 23:05 
GeneralRe: Better strategy? PinmemberMarc Clifton3-Sep-02 2:39 
GeneralRe: Better strategy? PinmemberGeorge3-Sep-02 23:53 
GeneralRe: Better strategy? PinsitebuilderPaul Watson4-Sep-02 0:13 
GeneralRe: Better strategy? PinmemberGeorge3-Sep-02 23:52 
GeneralRe: Better strategy? PinmemberChristopher Duncan4-Sep-02 1:43 
AnswerRe: Better strategy? Pinmemberjhwurmbach3-Sep-02 2:10 
GeneralRe: Better strategy? PinmemberGeorge4-Sep-02 0:09 
AnswerRe: Better strategy? PinmemberChristopher Duncan3-Sep-02 2:24 
GeneralRe: Better strategy? PinsitebuilderPaul Watson3-Sep-02 22:50 
GeneralRe: Better strategy? PinmemberChristopher Duncan4-Sep-02 1:31 
GeneralRe: Better strategy? Pinmemberbrianwelsch19-Sep-02 3:17 
GeneralEntertaining writing style... PinmemberShog92-Sep-02 19:25 
GeneralRe: Entertaining writing style... PinmemberChristopher Duncan3-Sep-02 2:09 
GeneralNothing original here PinmemberMarc Clifton2-Sep-02 14:26 
GeneralRe: Nothing original here PinsitebuilderPaul Watson2-Sep-02 22:54 
GeneralRe: Nothing original here PinmemberChristopher Duncan3-Sep-02 2:06 
GeneralRe: Nothing original here PinmemberMarc Clifton3-Sep-02 2:33 
GeneralRe: Nothing original here PinmemberChristopher Duncan3-Sep-02 1:59 
GeneralRe: Nothing original here PinmemberMarc Clifton3-Sep-02 2:48 
GeneralRe: Well written but where's the meat? PinmemberChristopher Duncan2-Sep-02 11:12 
GeneralRe: Well written but where's the meat? PinmemberChristopher Duncan3-Sep-02 1:47 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140415.2 | Last Updated 2 Sep 2002
Article Copyright 2002 by Christopher Duncan
Everything else Copyright © CodeProject, 1999-2014
Terms of Use
Layout: fixed | fluid