program development and documentation

Had an interesting discussion with one of my colleagues the other day. He said that the team he is working in has adopted a 'sprint' approach. I thought that was good, until he went on to say that he had no time to document the work that was being done. That is not at all good, and goes against one of the main principles - "Done means done". In my view, if work is not documented, then it is not completed. It becomes impossible to maintain, and hard for someone else to deal with when the originator goes on holiday (or is ill).

It is something I will bring up at the monthly staff discussion group next week.

Never assume

I booked a trip to an indoor ski centre, for my first ever snowboarding lesson. Seeing that I am an absolute beginner, and the snow centre has a main slope and a smaller slope, I assumed our lesson would be on the smaller slope, or certainly at the lower part of the main slope. How wrong I was. The lesson was up towards the higher part of the main slope. And we started by learning to control ourselves using the toe edge of the board. That meant we were facing up the slope with our backs to the way we were travelling!

Working on a system the other week, I decided to use only one of the two application servers, since they were identical machines with the same software loaded, and I only needed one machine for the test. I checked the settings, the test script I had written, the processor load and the network connection, but all to no avail - the test always failed. Over a week later, I tried the other machine and the test took just 2 seconds to run correctly. The machines might have been identical, but one of them had a hardware failure!

And I tell my students always to list their assumptions, and always check that the assumptions are valid. Now I have slipped up twice within the same week. One of the principles of the Baha'i Faith is "Independent investigation of the truth".