Time for a quick pop quiz. Roll your chair away from the desk, grab a pen and for goodness sake put down that fat free yogurt before someone sees you. (We know that some of you take good care of yourselves and live on things more nutritious than yesterday's pizza. It's okay. We promise not to tell.) Now, on to the business at hand. Taking no more than five minutes, make a list of every Windows application you know of that has never crashed and is absolutely, one hundred percent bug free. It won't do you any good to sneak a peek at your neighbor's paper. It's probably blank, too.
Do I sound just a bit cynical towards an industry that has been so good to me? You betcha. There's a row of battle scars across various parts of my posterior fighting for bragging rights, each of them from software projects that weren't all that they could have been. And I've never met an experienced programmer who didn't have the same.
The written portion of the quiz is over, so you can put down the pen. However, I'd keep that yogurt out of sight just in case the Stereotype Police show up unexpectedly. You know how they like nice, tidy little images that are easy to package and sell. Besides, you're making some of us feel guilty about that 8th slice of pepperoni supreme. Speaking of those who like to keep things simple and easy to sell, I notice that most of the folks from Marketing slipped quietly out the back door while we were taking the quiz. That's okay, we'll get back to them in a minute.
Am I saying that there's no decent software on the open market or in use within any of the gazillion companies worldwide who use Windows based systems? Certainly not. Like anyone else, I have my favorite apps and I've seen brilliant development efforts for which there are no worthy superlatives. What I am saying is that the level of quality control in our industry is, to be generous, embarrassing at best. There is no industry on the face of this planet with the lax quality standards of the software business. Further, our customers have been beaten into submission and in general not only accept but expect bugs in the software that they buy. It is the norm, and few question it. People simply shrug their shoulders and state that all programs have bugs, as if it's an irrevocable constant in life. More likely, it is a mantra they chant that has been taught to them by those wishing to move the merchandise.
Who's responsible for this mess?
Those of you paying close attention to your surroundings may have noticed that a few people from Marketing, who had crept back up and were peeking in through the back doorway, scattered at that last statement as if their lives depended on it. Who could blame them? After all, Marketing is without a doubt the developer's favorite scapegoat. Not that some of that reputation isn't well earned. However, like most things in life, it just ain't that simple.
Nonetheless, our business has evolved to such a state that being first to market has become more important than what we take to market. Feature lists are promoted long before a product is ready to ship (or we've even figured out how the heck we're going to make it happen, for that matter) as a form of preemptive strike against the competition. Mind you, I like to eat as much as the next guy, dietary considerations aside, and if it's between my tummy and one residing at The Competition, I'm rooting for the home team every time. Unfortunately, our arms race has escalated to the point of selling vaporware, something that should have been outlawed by the Geneva Convention ages ago. I offer a brief aside for your entertainment pleasure. It might interest you to know that I use a popular Windows based word processor that underlines misspelled words as soon as I type them, based on what it finds in its internal dictionary. It didn't so much as bat an eye at the word vaporware. Does that tell you anything?
Based on what we've seen so far, it looks like the Marketing folks who just scampered away won't be back anytime soon, as they're looking fairly suspect. Not only do we have a marketplace filled with promises of feature laden products that are "coming to a theater near you soon", we have trade shows, customer demos and countless dog and pony shows concocted by the very same folks. What's the end result of all this? A conversation that should be familiar to all.
Our intrepid Marketing rep begins with, "Hey, guys, how long will it take to implement all these new features?"
The developers, being generally straightforward by nature (I'm too polite to call us blunt), reply with, "Oh, about a year, if we start right away."
"Hmm. Well, I just made a major announcement to all of our clients that they can have it in three months. So, er, guys, uh, how long will it take to implement all these new features?"
Basic decency, not to mention a few specifically worded local ordinances, prevents me from detailing the rest of the conversation. I'm sure you know how it goes. Of course, the broken furniture always gets blamed on the hapless nightly cleaning crew, who never committed any crime greater than completely rearranging your desk to wipe off the monitor. Hey, it's a tough business. If you're not around to defend yourself, heaven only knows what goodies you'll end up getting volunteered for. That's why I never miss design meetings.
So, clearly, Marketing is the root of all evil, or at least the genesis of all buggy software, right? As I mentioned, things are rarely that simple. I'm not foolish enough to suggest that when the executives at the top of the food chain make a decision, we worker bees have veto power. Okay, well, I may be reasonably foolish, but I do have some finely honed survival skills. Regardless of how tempting it may be to Just Say No when someone come along with such an obvious disaster in the making, I've learned that it can be hazardous to the career path to stand up and make loud, contradictory statements. Nonetheless, if you just sit on your hands and go along with the game, you're part of the problem. Bold words, perhaps, but true just the same. Beginning to see how I've acquired some of those battle scars?
I have never in my life met a programmer who wanted to ship a buggy product. It's embarrassing. We bust our tails trying to come up with clever and elegant solutions, and it's just no fun to see our inspiration delivered to the market half baked. It's even worse still if such a poor decision leads to a well publicized bad reputation for what should have been a great product. The frustrating part of it all is that we very typically do not have final say over release dates. Such things are decided based on a business model, and if we don't have enough time in a normal day to make it happen, we're simply expected to work abnormal days.
If we don't have the political clout to override unrealistic release dates, what can we do? Give up, and continue to perpetuate the myth that all programs have bugs? Never. I'll flip burgers first.
Bad judgement in setting release dates is only one part of our dilemma. The fully expressed problem is that poor quality products in the market are the result of software being released before it has been completely tested and debugged. Somebody tell the Marketing guys that it's safe to come back in. There will be no lynching today.
The thing that is staggering to the imagination is that given this problem, our industry has only a small community of quality assurance professionals. There are good testers out there, but there are amazingly very few job opportunities. In all the shops where I've worked, spanning my entire career, only one has had a staffed, dedicated QA department. One. Everyone hires programmers, everyone hires technical writers. Very, very few hire testers. Is it any wonder then that even with a reasonable and well thought out delivery schedule our work far too often makes it into the hands of our customers with bugs? Some are so obvious that it's clear no one even tried that feature after the final build was made. Others are more subtle and difficult to reproduce, but no less embarrassing. Any non trivial computer program is a complex creature, with many code paths and lots of ways for things to go wrong. This is why we need professionals to do the testing.
So what can we do? A couple of things. If your shop doesn't have pro QA people sitting right next to the tech writers and programmers, start making the suggestion. How often and how loudly you do it is up to you, but make sure those around you and those above you know that you see merit in the idea, and why. Subtly or aggressively, as is appropriate for your environment and your job security, promote it. One of the reasons that there is so little professional testing happening in our industry is that we simply don't push for it. We want faster machines. We get them. We want top notch, productive development tools. We get them. Why? Because we ask for them. When was the last time you asked for testers with that same enthusiasm and persistence? Ask. You can make a difference.
There's another thing we can do. It's far too common for minor releases, demos, versions for training and especially bug fix builds to go out the door as soon as the compiler stops spinning. No build should ever leave the development department until it's been tested and banged on for at least a few days. We simply must build in time to do this. Lock the code down in version control. Nobody checks new stuff in while the test proceeds. If there's a problem, fix it and go back to square one on the test. You may not be able to test in tremendous depth given your circumstances, but you should at least sweep through all the features. And many bugs will never make it into the field.
How do you make this happen? Again, simply ask, propose, suggest, shucks, maybe even throw a few white board erasers if the person doesn't outrank you. If you don't ask for it, you don't get it. Sell your team on the idea, and sell your manager on it. This is not as difficult as you may think. You have tons of ammunition at your disposal. Point out how much time, money, effort, reputation, etc. has been lost due to flawed releases in the past. You may even have some spectacular examples to cite, although you should always be considerate of egos when you bring up previous disasters.
Simply put, as an individual programmer, you must make it a priority in your career to buy time for testing and to build a professional quality assurance group within the development department. Fight for this as you would fight for any deeply held conviction in a design meeting. What you may find is that your managers already believe as you do. Getting the support of the developers they represent can often give them the political edge they need to finally get the resources allocated.
In short, the squeaky wheel gets the grease. If you're tired of seeing your work put in front of customers when you know it could be better, stronger, tighter, dare I say, bulletproof, then you must stand up and be counted. We need time for testing, and we need professional testers. Programmers of the world, unite! You have a voice. Use it.
Top 