I’ve long favoured self-documenting code over code comments. But I’ve recently reconsidered the issue. After years of dealing with self-documenting code I’m beginning to see problems. With hindsight I’m less sure that self-documenting code is always the best way to go.
I recently read a paper on confirmation bias: the tendency to focus on information that corroborates theories and dismiss information that contradicts them. It explained a general problem that I’ve noticed with many scientific studies (particularly in the field of software development) but I hadn’t been able to identify.
When my Nan recently died, my parents got an education in the cost of dying. For example, if you want a cremation, you have to get forms signed by two doctors. Each signature will cost you about Â£60. My parents were told that this was due to the case of Doctor Shipman. A little research showed this to be a simplification.
Reading an entry on James Bach’s blog reminded me of the best tester I ever worked with. It got me thinking about how he did it.
Since reading about the PSP, I have continued to collect statistics. However, last week I decided to collect additional statistics related the the practice of reviewing code before compilation. The goal of this practice is to catch 100% of your compile errors before compilation by reading through the code. I was unsure about the wisdom of putting this responsibility on the programmer so I decided to gather some statistics to see if that doubt was justified.
that’s the software process, not the handheld. I’ve been reading Introduction to the Personal Software Process by Watts S. Humphrey (the creator of the process.) And I’ve been putting it into practice by gathering statistics on my current project.
It occurred to me the other day that video game characters run everywhere. I remember being chided by Lara Croft about that once. On the other hand it’s amazing how much time we waste each year doing routine tasks.
Jason Della Rocca has an article on the Escapist about investing in game developers and SPI (software process improvement.) As a game developer, I have no problem with the first part of this argument :) but the second is a minefield. SPI is too big a subject to fully cover in a single blog entry or article, but I will jot down a few thoughts raised by this issue.