A Mandatory Process

The second of a matched pair. That one was about requirements; this is about implementation.

This can be taken as a parable about development in a big organization.

A previous employer had developed a compliance process for reporting user application privileges on production applications. Reports went in XML to a mainframe. The general expectation was that these applications would usually be either Windows (.NET) or Java, for which easily-called libraries were available for ftp.

(The developers' manual was written in a way which suggested they assumed that the reader knew nothing about XML, and that Java development tools would be in use.)

They did not have anything readily available for Unix/C. My original encounter with it was for an application which I supported where generating the information was straightforward, but three months were spent before anyone could deliver a scriptable ftp (beyond "dump stdin into the default ftp process") for the Solaris environment involved. (I don't think I ever did get nftp installed.)

Some time later I was conscripted to finish up work on a reporting script for another Unix-based application. This one had a Perl component.

It amounted to: read a config file with user ids, join with the results of a database query, write out in XML, ftp to a given location on the mainframe (you could tell it was a mainframe because of some sector-related commands in the FTP).

I was dragged in because the original developer had used Perl, and I had a working knowledge of Perl. Nobody in the group that usually handled reports knew Perl and the actual business group didn't have anyone left with the skills to complete it. If it hadn't been a compliance request it would never have happened.

Development time, at worst, could be measured in a couple of hours. There were all sorts of delays resulting from the runtime environments; access (over two months for me to get access to the relevant environment); the fact that some columns in the production database, required for the report, were not populated (and when they did get populated, for the sole purpose of downloading to XML, some idiot put an ampersand into one field).

Actual elapsed time, first stage: three months, with some trailing activity.

Two months later, I got dragged in again: they had split the one application into two domains running on different servers with differing but overlapping user lists. They had to either merge these into one report or set it up with the other end as two reports. They did not seem to have anticipated this; it was an afterthought.

It might have gone the two reports way - I thought it best, it reflected the business model, the Unix sysadmin thought it best - but because he had had previous experience with compliance a development manager to whom I did not report and who was essentially a waste of air - I had dealt with him in other circumstances - was looped in to help deal with compliance and instead, because it would be an effort for him to do so, inserted himself into the process and insisted on going the one merged report route (so that it wouldn't be necessary to deal with the other end).

This meant extra time setting up secure FTP between the servers, and writing a Perl script variant on the principal server to pull over the file from the other server and merge the two files, made trickier by the fact that some duplicated users had different privileges on the two systems but could have only one record in the report.

Again, maybe a day's worth of development, in total: actual elapsed time, second stage: one month.

This was a high-priority process, and the requirements were simple and clear. What was essentially red tape filled up my mailbox and stretched the time to delivery out by a factor of, oh, twelve, assuming that reasonable time on top of one day's development would be four days testing and promotion, about a week to one day's worth of actual development work.