This has been sitting in draft mode forever… just discovered it and decided to let it rip.
——————————————————————————————————–
This post by “Uncle Bob” (and inspired by Jeff Atwood and Joel Spolsky) got my colleague Jim and I talking about quality and testing in software again. It’s a debate I feel like I’ve been having for my entire career in software development. I’ve often found myself taking extreme stances like “testing is a waste of time” or “quality doesn’t really matter” to get a point across. But of course, we all know that testing is important and that quality does matter. Behind the work that most of us do, there are very real business constraints. We don’t have infinite resources and neither do our customers. So the key take away is that there absolutely is a point where quality no longer matters. A point where quality improvements will not add to the value the software is creating.
I’ve done a lot of hiring over the years and have usually passed on folks that want to talk about code coverage in testing. Not because I don’t think they are good engineers, but because I know we don’t share a common philosophy. I’ve found that quality enhancements, like features, need limits. I like engineers who feel strongly about testing and code coverage on the highest value and highest risk components of the application. But for the other stuff, will do the best they can without having to double the code base with tests. At my current shop, nextpointlab.com, we have golden rules that govern everything we design and build. Places where mistakes matter and would really hurt us and our customers. Not every feature is as important as the next… in most applications there are probably two or three things where quality is absolutely critical.
