Changing Functionality – PTF or not ?

A while ago (we are talking 7 or 8 years) I was involved in construction a portion of a large system which required that a data item be assembled from a number of smaller data items into a long 800 byte string.

Simply speaking, we were concatenating a number of views on to the end of each other to form the resultant export view which we then used. The usage of the result was by a number of third parties (note that this was pretty much before the widespread use of XML for data transmission, so we had to form our own standards which we agreed with the 3rd parties).

The point in all of this was, that after installing an generator PTF to our remote encyclopedia environment as a prerequisite for a fix that we really needed, things started to go awry.

The large 800-byte concatenated view didn’t look right, so we investigated what was wrong.

In the view that we were concatenating into, (defined as variable length), prior to the “fix” it was actually storing trailing spaces from the constituent views, so we didn’t have to worry about padding. Apparently this was incorrect behaviour, so was then fixed by the prerequisite PTF to the generators.

This now caused us a problem, as we had depended on (admittedly) incorrect behaviour previously to allow us to get the results we wanted. NOW, with the PTF applied, the behaviour was corrected and we were stuffed !!!!!

We basically had to rewrite much code to take account of the fact that trailing spaces were no longer stored at the end of a variable legth export view – this took longer than we thought, as analysis showed many more instances of this than we expected.

Move forward to today, and during a large Gen upgrade on the same site, we discovered that things that have been previously working are now not, simply because of “corrections” in new versions of Gen and recodings will be necessary in some cases.

Now I know that the situations described above are not Gen-specific, but what I think would alleviate the situation is better documentation at the outset, so that us developers can see if a function is actually doing what it says in the documentation. In my opinion, no longer is it enough to say that a function “does this”, but it should give detailed examples, illustrate usage, and limitations. This should be similar for events, too as some event stacking priorities have changed over the years.

When things like this change, if they were documented, then people who manage systems can perform proper impact assessments of upgrades.

OK – the situation is better than it used to be, but compare the documentation that comes with (say) VB.Net with Gen documentation – need I say more ?