I once heard the writer Anne Lamott describe what she did with each new piece of writing. She would send a copy to a good friend and wait for a response. Even after choosing the fastest possible overnight delivery, she had nearly 24 hours to dread the phone call she would receive. Already convinced of the response, she would spend this time carefully enumerating every one of her friend's character flaws.
When I first heard it, I found this story funny -- but it doesn't seem humorous to me now. You see, I've been writing a programming book, and the publisher took an early draft and sent copies to three reviewers. I was pretty much oblivious to this until I received the first review in the mail. It was devastating. The second one was even worse.
Each review listed problem after problem. One review included a list of misused words, another delved into more serious questions about my choice of material. Worst of all, it was clear that each reviewer was a knowledgeable expert, whose opinions couldn't be easily discounted. After months of work, I suddenly felt I'd accomplished absolutely nothing.
The most sobering part of this experience is that the criticism, hard as it was on my ego, resulted in a much better book. I sat down and spent weeks rewriting much of the text, reorganizing the chapters, and bringing in new material to address the shortcomings pointed out in the reviews. The draft I sent to my publisher this morning is so much better, it's a little scary.
A similar sort of review could help a lot of software products. I'm not talking about a "software review" like those in magazines, nor even typical end-user beta reviews. The software critique I have in mind would focus on the code itself and pull no punches -- it would be harsh, blunt, obnoxious, and painfully honest. It's probably no coincidence that the most useful review I received was also the harshest.
As a software developer, I've had "code reviews" where I went over my code with someone else and, in the process, uncovered a few bugs. But I've never had another developer point out that the collection of classes I'd spent weeks refining was completely unnecessary. I've never had a "code review" that seriously questioned basic design issues.
Of course, when I've reviewed other developers' code, I've not pointed out such flaws, either. In part, that's because criticism is inherently confrontational, and takes an emotional toll on both parties. But more importantly, good criticism requires a lot of hard work. To criticize something, you have to understand it thoroughly, and you can't gain such understanding from a few moments of informal discussion.
Software developers already use a variety of mechanisms to double check their software. But none of these is a substitute for good, professional criticism. User feedback and marketing surveys, for example, tend to reflect the needs of a vocal minority, and often emphasize features over quality. Usability testing, on the other hand, often concentrates too narrowly on a "typical user" in a "typical situation." Good design has to tread a narrow path between needless generality and restrictive specificity.
Of all the existing mechanisms, the closest to the idea of software criticism is called "design review." But there's a subtlety here -- it's insufficient to critique the design just once, then proceed to implement it. The design needs to be continually challenged, examined, and revised as the project moves forward. Review and criticism need to be an integral, ongoing part of the development process. In the ideal development environment, the processes of design, review, criticism, implementation, and testing are all tightly integrated, with each one affecting all of the others.
I'm not claiming that anyone should ignore user feedback, stop usability testing, or give up on code reviews. Each of these is an important part of good software development. Each addresses specific issues that deserve consideration. But as developers, we need to learn how to put product quality above our own egos, and we need to be able to honestly give and receive pointed criticism.
It's not easy, but if it makes better software, maybe it's worth sacrificing a few egos.
--Tim Kientzle