Tuesday, February 22, 2005
his time has come
Yesterday was our baby's due date, and it came and went without incident. We decided to try and induce the labor, so we're going back tonight to do that. With any luck, we'll have the little guy here by week's end, but there is a chance that the process won't start the labor and we'll be forced to just wait it out or look into other alternatives. It oughtta be real fun tonight, because my wife will be forced to lay on her back for about twelve hours or so. I also don't have the first clue what I'm going to do for those twelve hours either, especially without an internet connection. Guess I'll get to catch up on my reading.....
Tuesday, February 08, 2005
lament for a tester
Why does it have to be impossible to sell management on the concept of dedicated software testers? Testing is a vital part of the software development process, yet too many organizations (mine included) only pay lip service to the idea.
Around here, I feel that many hold the belief that software bugs are the programmer's fault and that they are to blame for producing faulty code. If you're of this mindset, here's a little excercise for you. Take 30 minutes and write a 2-5 page essay. Check and proofread it all you want. After that, hand it off to someone of equal or greater literary competence (no fair having your two-year-old appraise your work), and see if they can find any mistakes. Any at all; even a small one. Chances are quite high that they were able to find at least one mistake.
Even the best authors make mistakes in grammar, spelling, or punctuation; it's inevitable. That's why authors have editors and various other proofreaders. These people exist as a check to make sure the author (and the publisher!) doesn't embarass himself by publishing a novel rife with grammatical errors. Why then should writing code be any different?
Programmers make mistakes. As is the case with authors, this fact is inevitable. Don't ever believe that a programmer wants to produce shoddy code. That just doesn't make any sense. To a programmer, code is just like that novel is to the author. It's an achievement. Something to be proud of. But sometimes, the user behaves in ways that the programmer would never in his wildest dreams expect. They double click the mouse when a single click would suffice. They type passwords in with the caps lock key on. Users are all different and see things differently than programmers. Without a second set of eyes on our work, there will be bugs, and should be expected.
This is where testers come in. Testers should work closely with the programmers, helping to greatly reduce the chances that a bug will find it's way out into the open. Without a dedicated QA team, can you really hope to release anything that isn't of beta quality at best? Remember the old adage about a million monkeys on a million keyboards? That's what we need. We need testers to turn the caps lock key on; to type in 3,721 characters into a text box; to stand on their heads and recite the national anthem while drinking orange juice and clicking the mouse. Most of the time, it won't take that much effort to find a bug, but many times, the really interesting and elusive bugs take just this amount of dedication to find.
I could go on for pages more about the need for good software testers, but instead, I'm going to link to an article Joel wrote, that I find particularly fitting.
The Top Five (Wrong) Reasons You Don't Have Testers
Around here, I feel that many hold the belief that software bugs are the programmer's fault and that they are to blame for producing faulty code. If you're of this mindset, here's a little excercise for you. Take 30 minutes and write a 2-5 page essay. Check and proofread it all you want. After that, hand it off to someone of equal or greater literary competence (no fair having your two-year-old appraise your work), and see if they can find any mistakes. Any at all; even a small one. Chances are quite high that they were able to find at least one mistake.
Even the best authors make mistakes in grammar, spelling, or punctuation; it's inevitable. That's why authors have editors and various other proofreaders. These people exist as a check to make sure the author (and the publisher!) doesn't embarass himself by publishing a novel rife with grammatical errors. Why then should writing code be any different?
Programmers make mistakes. As is the case with authors, this fact is inevitable. Don't ever believe that a programmer wants to produce shoddy code. That just doesn't make any sense. To a programmer, code is just like that novel is to the author. It's an achievement. Something to be proud of. But sometimes, the user behaves in ways that the programmer would never in his wildest dreams expect. They double click the mouse when a single click would suffice. They type passwords in with the caps lock key on. Users are all different and see things differently than programmers. Without a second set of eyes on our work, there will be bugs, and should be expected.
This is where testers come in. Testers should work closely with the programmers, helping to greatly reduce the chances that a bug will find it's way out into the open. Without a dedicated QA team, can you really hope to release anything that isn't of beta quality at best? Remember the old adage about a million monkeys on a million keyboards? That's what we need. We need testers to turn the caps lock key on; to type in 3,721 characters into a text box; to stand on their heads and recite the national anthem while drinking orange juice and clicking the mouse. Most of the time, it won't take that much effort to find a bug, but many times, the really interesting and elusive bugs take just this amount of dedication to find.
I could go on for pages more about the need for good software testers, but instead, I'm going to link to an article Joel wrote, that I find particularly fitting.
The Top Five (Wrong) Reasons You Don't Have Testers
Tuesday, February 01, 2005
a friend takes his leave
My colleague and friend had his last day with the company yesterday; moving on to bigger and better things. We've been working pretty closely together for a little over a year on our current project, so it's sad to see him go. We've had both successes and failures, all the while helping to refine and better the other in our craft. I've learned a lot from him over the last year or so, and can only hope that I've been as influential to him as he has been to me. It will be different here without him around, but at least he hasn't gone too far, so it's a good bet that we'll still see him around from time to time.
Thanks, Jay, for all that you've done. For helping me to become a better coder, for pushing me when I needed it, for all the support you've given, for putting up with all my "what if?"s throughout the months, and for being more than just a co-worker. It's been a wild year, but a great one. I wish you all the best in your new position!
Thanks, Jay, for all that you've done. For helping me to become a better coder, for pushing me when I needed it, for all the support you've given, for putting up with all my "what if?"s throughout the months, and for being more than just a co-worker. It's been a wild year, but a great one. I wish you all the best in your new position!
Subscribe to:
Posts (Atom)