R. Young got his first job as a developer right out of college. He was a Programmer Consultant I, which meant that he'd be sent to a client site to fix bugs in some old system. But on his first assignment, he got lucky: the client actually wanted him and the junior-level programmer to develop a small application.

The application they wanted wasn't too complicated, and primarily consisted of printing out a few reports. Although neither Young nor his colleague had worked with the client's language of choice - Clipper, an old DBase derivative - they were able to pick it up pretty easily and learn its nuances. The first thing they realized about Clipper was that, instead of the recommended SEEK command - which required USEing an INDEX or two, SETting RELATIONS, SEEKing a search expression, and looping while FOUND() was .T. (that's "true" in Clipper-speak) - they could simply use a filter with the SET FILTER command. All one had to do in order to, for example, print Line Tests results for a given operator was something like this... 

USE LineTests
SET FILTER TO PerformedById = nOperatorId
LIST DateRun, AreaTested, WasSuccess TO PRINTER

It was so much simpler. He and his fellow developer applied this technique throughout the application, all the while avoiding the complexities of SEEK. However, when they put their application in production and imported all of the production data, they noticed it ran a little slow. Especially when it came to reports.

On most other applications, the dot matrix printer head would fly back and forth at a dizzying speed, sending nearly twelve-pages of greenbar to the output bin. But on Young's application, the printer ran like this... 

bzzzzbbt bzzzbt bzzzbt bzzt bzzt bzzzzzz shrrrrrnk
... one one-thousand, two one-thous--

bzzzbt bzzzzbbt bzzzzzz bzzt bzzt bzzt bzzt bzzzzzz shrrrrrnk
... one one-thousand, two one-thous--

bzzt bzzzzzzzzzzzzzzzt bzzbt bzzt shrrrrrnk
... one one-thousand, two one-thous--

Fortunately, the client didn't seem to notice or care. The application certainly wasn't a critical one, and Young had just assumed that the slowness was a result of the large amount of production data. Of course, this wasn't the case at all. In all their excitement over the SET FILTER command, Young and his colleague missed one important part of the documentation. 

Note:  Although SET FILTER makes the current work area appear as if
it contains a subset of records, it, in fact, sequentially processes all
records in the work area.  Because of this, the time required to process
a filtered work area will be the same as an unfiltered work area.

By the time Young learned this fact, he had been reassigned to another client and had long-forgotten about this application. Years later, however, he stopped by his former client's office to visit some friends and had his memory jogged by the intermittent hum of a dot-matrix printer.

bzzzzbbt bzzzbt bzzzbt bzzt bzzt bzzzzzz shrrrrrnk
... one one-thousand, two one-thousand, three one-thousand, four one-thousand, five one--

bzzzbt bzzzzbbt bzzzzzz bzzt bzzt bzzt bzzt bzzzzzz shrrrrrnk
... one one-thousand, two one-thousand, three one-thousand, four one-thousand, five one--

bzzt bzzzzzzzzzzzzzzzt bzzbt bzzt shrrrrrnk
... one one-thousand, two one-thousand, three one-thousand, four one-thousand, five one--

And then it all came back to him. He went over to the department manager - whom he had a good rapport with - and begged to let him rewrite the program. He wouldn't charge a dime, and would do it all in his free time. Young just didn't want his name associated with such a beast. The manager was kind enough to let him and, a few weeks later, the dot-matrix printer was once again spilling out pages.

Did you fill out the WTF reader survey yet?

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!