Have you ever done something that seemed like a good idea at the time? Then looked back upon it much later and had second and third thoughts about the wisdom of what you had done?

A long time ago, Jack worked for a company that had built a goods-declarations system for freight-forwarders so that they could get the blessing of the government to import/export their goods.

Those were the days when DOS was the latest and greatest thing available for anyone who wanted quick development turnaround time. No big-iron, with all their rules, regulations and procedures for these guys. They needed their software written to their specifications to solve their problem in short order.

To this end, they had built a framework around the features available in DOS. One particular item in their framework was a "text box" into which one could type, ahem, text. Of course, like everything else in computer science, there was a practical limit on how big things could be. Since the screen was pretty full, the biggest number you could enter into this particular field was 99,999.99 (mostly as a limit of the maximum number of characters you could fit on a monitor).

Now this may have been fine and dandy for schooners and other such sailing ships. But, as ships got bigger, they could carry far more freight. The shippers made repeated requests to enlarge the input-field to enable them to enter bigger numbers.

Of course, this would involve several significant efforts:

  • Make the text box scroll so that bigger numbers could be entered
  • Change the size of the quantity field in the data file(s) to handle bigger numbers

The initial response back to the shippers was No; you can split that shipment of goods into multiple lots, and do separate customs-clearances for each lot.

After a while, the shippers got tired of doing multiple copies of the all of the customs paperwork for every shipment and insisted demanded that they be allowed to enter bigger numbers.

Rather than just do the work to allow bigger numbers to be entered, the managers came up with a scheme to enable bigger numbers to be represented in the same number of digits; they would create new units of measurement:

   1000 KGM = 1KK (Kilograms)
   1000 LTR = 1KL (Liters)
   1000 MTR = 1KM (Meters)
   1000 UNT = 1KU (Units)
   1000 PKG = 1KP (Packages)
   ...and so on

A convenient side effect of this was that since the names of all of the new units were exactly 3 characters long, they fit into the existing database units column.

The management proudly displayed their new capability to their customers, who promptly inquired WTF?!, which led to all sorts of time-consuming training to get them used to the new home-grown unit systems.

Once the shippers got used to it, things settled down. Until...

By multiplying everything by 1,000, some accuracy was lost as the numbers got bigger. For example, for a client to enter 12,345,675 litres of fuel, they had to enter 12,345.68 and change the units to 1KL. Naturally, the shippers were concerned about the extra 5 litres of fuel that were just added. It's a big ship; no one will worry about it! But then we'll need to pay duty on those extra 5 litres. In that case, do two customs entries, one for 12,345.67 x 1KL and one for 5 x LTR.

Again, the customers groaned about having to do multiple sets of paperwork.

But the customers didn't have the worst of it. The developers needed to write routines to convert those new units back to the real numbers before displaying them in reports.

Thus, after the countless hours wasted writing thousands of lines of code to handle custom units and convert back to normal units for reports, it would have been far more efficient time-wise, and substantially less effort to just make the original text box scroll and enlarge the field in the data files.

But it seemed like a good idea at the time.

 

Photo credit: trekkyandy / Foter / CC BY-SA

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