Improving the In-basket

Four years ago, I wrote a series of blog entries about an exam which the Occupational Psychologist uses called 'The In-basket'. A few weeks ago, we had a discussion about this exam in which she outlined a few changes/improvements which she wished made. There is, unfortunately, no correlation between the apparent simplicity of each change and the simplicity of implementing each change: frequently, seemingly simple changes are hard to implement whereas seemingly complicated changes are easy to implement.

So it was this time. The hardest change to implement was probably the addition of tags (or labels) to each post; the initial idea was that the examinee would go over the items in the inbox, define a tag for each item, sort according to the tags then deal with each item. The implementation required several hours spread over a number of days before it was bug-free. The addition of such tags (and other new fields) required changes in the structure of the file which is written holding a log of all the examinee's action - and of course, the parser which later reads this file has to be changed and the program which prints out the results in human form also has to be changed.

As the exam itself is quite complicated and certainly not structured like a regular, multiple choice, questionnaire, it took some time to remember exactly how the program works and how the output is defined. Only then could I start adding new functionality. One of the side effects of my rewriting parts of the program is that the file structure is now documented.

Originally, the results program used to create its output via Word automation, laboriously sending line after line to the Word object which was created at the beginning of the routine. Apart from being slow, this approach also suffers from the problem that should the program fail during the output stage, an invocation of Word would be left orphaned in memory. These days, I create the output using HTML which is faster and safer, then insert the complete HTML code into Word. Sometimes the Word code can be converted very quickly into HTML, but in this case, it took about an hour and a half to rewrite the code, which is about ten times as long as it normally takes. 

I have now passed the program onto the OP for her final testing before we deploy the new versions. I hope that there won't be much to correct or improve, although now my renewed understanding of the program is much deeper than it was a week ago.