Linked by Eugenia Loli on Mon 11th Jan 2010 08:10 UTC
Permalink for comment 403592
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
More News »
Sponsored Links



Member since:
2006-01-06
I wasn't sure if you were posting this as a tongue-in-cheek joke or not, because it's hard to conceive that anybody would post anything so asinine -- and actually believe what they're saying. It's just wrong on so many levels and, if this is what the devs on this project believe, then it's no wonder that the quality is so poor.
Look, as a developer, it's your RESPONSIBILITY to make sure that your code is as well-tested as possible before you release it. You can't defer this responsibility to someone else. You own it. I'm not suggesting that you can't use the help of other people. What I'm saying is that YOU own the quality of your code, and you need to take responsibility for it. You can't blame other people for not finding your bugs. The software engineering process should include time to write solid unit tests that exercise as much of the code as possible. The unit tests should run with each and every build. It's also advisable to create integration tests, if you need to integrate with other components. Many companies offload the job of integration to testers, but there's no reason why developers shouldn't be writing these tests.
Now, of course, it doesn't hurt to have additional people testing your code, but that shouldn't be your sole line of defense. Use private or public betas to get more code coverage. The point is to exercise as many codepaths as possible, and remove as many defects before release. This is more of a partnership between dev and test than a dividing line.
Show me a developer who says that he can't test his or her own code, and I'll show you a poor developer. I would never hire anyone with that kind of attitude. The best software engineers test their own code. Period.
Google doesn't hire testers. There's a reason for this. Developers know their code better than anyone else. Certainly, there are conflicts of interests, where a developer may not want to reveal bugs in his or her code; or, perhaps, he or she may lack sufficient vision to find their own defects. But that's not a fundamental problem with the engineering process. It's a problem with the INDIVIDUAL. Fix that -- and you produce a solid product. Ignore it, and you produce crap.
/soapbox
Edited 2010-01-11 19:19 UTC