A new week..

The flu is almost gone now. The weather has been extraordinarily wonderful the last couple of days. Sad to say, but I've had to watch the sunshine from inside the apartment. Today I finally went out for a walk. I ended up in Saturn buying CD's and accessories for my computers. But it was nice seeing the terraces open with people enjoying them in T-shirts. It is the middle of Oktober and it's 25 degrees centigrade! It should be raining cats and dogs by now! At least that's what I think is going on in Finland.

Here's a thought (not mine, but I liked it):
Why should one be like the others, there are already so many of them?

The stacks of stuff that have been all over the flat for a week now were cleared away today. Most of the stuff I just put in little cardboard boxes to wait for further organizing. I started thinking about my white paper. I should definitely write one. And try to get it approved by a committee for some conference. Or write for a professional publication or magazine. Something titled "What's wrong with traditional code reviews?", naah, that's not catchy enough. But the idea is to present some typical ways of doing reviews (document or code) and contrast them with the technique I've developed over the years. There are many things that can go wrong and actually make the practice of reviews so inefficient that they eventually don't get done at all.

For one thing, why are you doing a code review/inspection in the first place. If you're doing it to find errors, you're probably already on the wrong track. If you're trying to explain what the code is doing (a typical walkthrough), you're not doing it right. The code should explain itself (along with comments, of course). If you're trying to execute the code in your mind, wrong again!

If you think you always need to have a meeting to have code reviewed, think again. If you have no role division or don't divide the material and responsibilities among the participants, you're wasting effort. And such things. By presenting the current practice, I could easily show how much more effective and efficient my practice is and how it therefore has a higher chance of becoming a habit in an organization. Getting a quality assurance method to become routine is the best you can achieve as quality engineer. Through regular usage, you have all time in the world to achieve your quality goals.

Comments, anyone?