Drawing parallels

One of the most common methods for us to learn is by analogy, establishing parallels between two situations which, not being identical, have sufficient in common that the lessons learnt from one might be of application to the other. This is what happens for instance if you come late to an appointment because the traffic downtown is crazy due to Christmas shopping and you reach the reasonable conclusion that the sidewalks will be equally collapsed, so you allow yourself more time if you need to go in there. Technically speaking, car and pedestrian do not have to be correlated, but sometimes you have a reason to consider them related and you draw your conclusion.

For me, my job as a programmer is an endless source of analogies to my life in general. Even if the work is not simple, the working environment is a lot less convoluted than life, with just a few boundary conditions and a bunch of agents playing in. Today I had a funny situation that extrapolates very well to the real life and shows how cutting corners today might impose painful costs further down

         Photo: pixabay

Although I was officially on vacation, there was an operation slot for our instrument last week and I checked the result in case I found anything urgent to solve. It turns out that a recent piece of software that I wrote contained a bug. How is this possible? Well, with embarked systems it is not always possible to test everything before you deploy it. But in this the addition looked simple enough that I did not consider testing it: Wrong!

Lesson 1: Even if you think you know the result of a test, it is always a good idea to give it a try just in case. This is all the more true if the test is easy to run.

This is like checking the door when you go out of the house. You "know" that the door is closed, but just giving it a push does not cost much and it will ensure that you are not mistaken. 

But how comes that I was mistaken in my code? The problem is that I had violated guidelines 3 and 7 of the Zen of Python: not only had I written a function that was complicated, but it was also hard to understand, so I fooled myself and tried to use the function in a different way from what it was designed for. (Incidentally, the instrument is not programmed in Python, but most of the guidelines still apply.) Martin, who was on duty the day the error happened, quickly diagnosed it an proposed a new function name that should replace the original one, but with a caveat: the old function, when used adequately, was really very useful, so it is used in many places throughout the code, but the fix is not as easy as just searching and replacing in all the files. We have done this in the past a number of times with great success, but in this case we also have to change the rest of the line. The change in itself is not very difficult: there might be 50 cases which need to be replaced, but the problem is checking that the replacement works as we intend it to.

In most software endeavors, there is an automated system to test that the software still does everything that it is supposed to do, even if you changed it, just to ensure that these changes did not break a working functionality. This is called "regression testing" (as in "something that used to work does not work anymore, so instead of progressing we are regressing"). Unfortunately, there are significant portions of our software which are not covered by our automatic testing system because the tests are too difficult to build. Wrong again!

Lesson 2: If you choose not to do the things the right way, chances are that they will come back at you and bite you.

If we had the tests in place, the change of the code would take less than an hour and the tests could eventually run overnight. As it is, it would probably take a week or two to make and test all the changes that need to be made. Of course, we do not have that kind of time, so instead we will make the most urgent changes and try to keep in mind to propagate the change to other parts of the code as they get updated for other reasons. In this way we will know how to apply the change and make sure that it works. Things will eventually get fixed, right? Wrong one more time!

Lesson 3: If you cannot fix everything, fix at least the most urgent and leave the rest for later, but make sure to allocate time in the future to catch up at some point.

As you can see, all these situation hold very strong similarities with real-life, be it cleaning the rain gutters, where you can remove the thickest lumps, but that will not save you from cleaning the rest, to writing the shopping list, which you can prepare halfheartedly... only to find that you forgot to buy milk.

I apologize if the post turned out patronizing, because it was not the intent: I just tried to exercise a bit of self-loathing, commenting on my own shortcomings and eventually crack a laugh at how one can unknowingly run into a tricky situation. Enjoy the evening.