Minor Features

Quality Assurance involves more than just testing. It means doing whatever is necessary to meet the Dev team's ultimate objective: shipping quality software on time. True, the QA staff spends a majority of its time testing. But in most organizations, QA is expected to play a customer advocacy role (often moreso than the programming staff). A good software team relies on QA to provide useful feedback on feature design specs, usability testing, beta programs, and so forth.

One time I was assigned to test a new feature, which had been originally intended to be fairly minor, for some server-based application. The feature was so minor that Product Management didn't even bother drafting a functional spec, unless you count a couple of sentences in an email. Basically, they wanted the product to save off its raw input data stream into binary files, for possible processing by an external tool to come later (TBD) that our customers were never going to have to see.

The programmer who got this assignment took his cue from Product Management and immediately went to work banging out the file storage feature without drafting an Architectural Design doc. Despite the name, this type of document is usually quite brief. It's basically a proposal outlining the anatomy of the essential guts of the feature, in just enough detail for another programmer to review it over a coffee break. It is also relied upon by QA for designing their tests. But that didn't exist in this case.

Anyway, the data logging feature shows up in the next build without much advance notice. I have no functional spec and no design doc. So, for the time being, I am left to my own best judgment about how the feature ought to work.

The one thing that immediately stands out is the autogenerated filenames. The programmer had reasonably decided that each data file should bear the timestamp of its creation time in the filename. Which makes perfect sense, no arguing with that. The problem is, the programmer decided that the best approach for a timestamp was to use UNIX time. That is, the name of each data file created by our product was the number of seconds elapsed since the UNIX epoch. Hence, a data file created on Friday February 13th 2009 23:31:30 GMT would be given the incomprehensible filename 1234567890.dat.

So I filed a bug against the file naming convention. My rationale was that maybe someday our customers might need to browse through a large folder of these files, looking for data from a particular date and time. I suggested that 20090213233130.dat would be a lot easier for a human being to parse in a listing of files than 1234567890.dat, despite the longer name. My bug was deferred as a future enhancement, with the stated rationale being that our customers were never going to see these files and so the obtuse names didn't matter.

If only the developer had circulated a design doc, I could have made my recommendation before the code was ever written. Then the whole situation would have been moot.

In the end this minor data logging feature, which had been implemented without a feature spec or a design doc, subsequently gained greater prominence. It was relied upon by other internal components of the product and even advertised as a useful feature for our customers. But by then the entire team was stuck with the unhelpful naming convention for those data files, because other code actually relied upon the once-arbitrary file naming scheme.

The moral here? There are no minor features, only features that look minor today.