Chaining functionality

I see that I've hardly written any blog posts this month; it's not because I've been sunning myself in the Bahamas without access to the Internet, but rather because I've been too busy at work with all sorts of activities which aren't of much interest here.

As it happens, there was a nice coincidence of events the other day: the same procedural issue reared itself both at work and also with the Occupational Psychologist, so I feel that I can write about it here.

At work, there was someone who wanted that orders be marked after she had printed labels for that order. I asked her how she printed the labels and here was the explanation (my words):

1. I run program A which extracts data from the order and places them in a temporary table
2. I run program B which prints labels from that temporary table
3. I run program C which deletes all my entries from that temporary table.

The OP had something similar:

1. Change status in a docket
2. Add default meetings to that docket
3. Print the checklist of exams for that docket (based to a certain extent on the meetings for that docket)

In both cases, I was able to suggest a change in their work-habits which reduced the amount of overhead: I suggested that they chain their activities. Of course, such chaining is dependent of the programmer and not the user. In the first case, I added to the beginning of program A the command to delete entries from the temporary table, and at the end of the program, I added the command to print the entries in that table. I also suggested to the user that she run the program from within the order screen itself, which saves having to input the order number to the program. All she has to do now is press a button and the labels print automatically.

In the OP's case, changing the docket's status to a certain status will now cause the default meetings to be added to that docket, and adding the default meetings will cause the checklist to be printed (or more accurately, displayed in Word, prior to printing).

In both situations, the original programmer concentrated on atomic activities: this is correct, but can be improved. In the work situation, there are many programs which have to print labels and it is advised always to clear the temporary table before adding new values. So these activities are written once and called many times. But chaining these activities together didn't require me to "reinvent the wheel": printing the labels is accomplished by adding a print stage to the original program, and cleaning the user table is a one line SQL command.

I have noticed that users tend to have a very data-centric or atomic view of their activities whereas I tend to have a more process-centric view which works at a higher level. Hopefully, adding these two higher level programs will open the eyes of the users to the fact that with a little glue, one can work at a higher level, achieve more in less time, and minimise the overhead.