Central America 2005

A blog of my Central America experience. Get my RSS feed using awasu or bloglines. You can also register to the google group to get an e-mail for each publication. A syndication of the photos only is also available.

Saturday, April 09, 2005

Miscakes

I know, I know I should write about my crazy nights in Madrid and Chicago, but I have this debt I wanted to write about before I left Israel. So for now this is it... Next time I guess I'll be blogging about my trip.

A couple of gays ago I discussed with Vider the problem of spill checking. We all know that spill checkers can't catch some of the spilling mistakes we cake. Actually, than they can leave us with some humiliating and funny mistakes that show the world we can not tell the difference between 'then' and 'than'.
It immediately reminded me what Watts Humphrey suggested to do with a similar problem we have in software engineering. Every programmer knows that automatic tools (compiler, lint) catch many mistakes we do when we program. Still, these tools leave us with problems in the code that are similar to those that the spell checker leave us with when we Word something.
So, what can be done about it? What tools are there that can help us eliminate those mistakes? Well, there is no replacement to using our brains. A review is probably the only real solution. So, the suggestion is to start with self-reviews, turn to the automatic tools, and finish with peer-reviews. Notice that the self-reviews come before the other techniques. There is a big advantage to this approach. You learn much more from mistakes that escaped your self-review and come up at the automatic tools and peer-review phases. These are not typos, but real mistakes. Eliminating those mistakes on future work will save valuable time. This promotes the habit of "doing it right from the first time" which should become a second nature in order to improve quality in anything we do.
Keeping statistics of these mistakes and categorizing them, as suggested in "Introduction to Personal Software Process" (a recommended book for all SW practitioners...), can become a quite valuable source of defect data. I guess these strategies can work even when you write a book, a blog or a letter. But for now it would seem awfully square headed to try to do these things. Oh well...

0 Comments:

Post a Comment

<< Home