Humans are very practical beings. When we need one tool, we're very happy to misuse another tool to get the one that we want. The extreme example being the lowly paperclip - in one study (admittedly done several decades ago), only one paperclip in 10 actually got used to clip papers together. The rest went to a variety of uses, many of which involve the wire being bent until it becomes a different tool. Or even just mangled as a convenient outlet for a desire to fidget.

However to the toolmaker, these creative uses are often flabbergasting. And as programmers, we are often in the position of being the astounded toolmaker.

Here is an example that happened to me.

The first real piece of software that I wrote was meant to be a desktop tool for understanding how much business Bristol-Myers Squibb did with its various suppliers. All of the receipts from their various North America operations were collected together by one department, which then categorized what everything went for and attempted to spot areas where they could negotiate a good contract with a single supplier and save money.

This was very successful, with savings in the hundreds of millions of dollars. But there was resentment in the rest of the company since they had to hand over a lot of accounting data, and didn't have any way to understand for themselves what we understood.

The tool that I wrote was supposed to solve this problem by letting every other department know what we had found out about them.

So I put a lot of work on building the best tool that I could for this purpose. I had fairly strict performance criteria, it had to run with a large dataset on a 486 with acceptable performance. Being user friendly was critical. And, of course, I tried to make it as easy as I could to get whatever information you wanted out in any level of detail.

The tool was rolled out, and achieved its goals. However its primary success was in achieving a goal that nobody knew we had. While I had meant to build a top-notch tool to understand where money went, I had also built a passable address book. You could rapidly find anyone who BMS did business with in the previous 3 years. And right there you had their name, address, and phone number, which you could use to do business with them again.

Afterwards we estimated the cost of that not-great address book at about $1,000,000 US.

So, what stories do other people have of cases where the tools that you built got used in ways that you weren't exactly planning on?

Update: "one one" became "only one". Thanks, grinder. He also corrected Sqibb to Squibb...

  • Comment on That screwdriver looks like a hammer...

Replies are listed 'Best First'.
Re: That screwdriver looks like a hammer...
by BrowserUk (Pope) on Aug 23, 2004 at 07:35 UTC

    Six or so years ago, I started out using tail -f log to help debug an hp/ux-based system that used a central log of communications with many remote systems. I had to re-write the system tail utility so that it followed the logfile by name rather than file handle, as the logs cycled whenever they reached a particular size. That quickly progressed to being filtered using grep to just certain key events.

    With a scrolling log of many, concurrent communications, it was difficult to keep track of the one or two of interest. So that got fed into awk, which filtered only the latest event for each machine, sorted them by machine id, discarded those that had completed, and displayed the most recent 60 (the biggest screen size available).

    Slowly, with the addition of a few ansi escape sequences to clear the screen and highlight the latest changes, the one-time debugging aid became more useful (current and immediate) than the system reporting tool and rapidly became the tool of choice for many of us on the project.

    There was talk of re-writing it into something easier to maintain that Awk(ward), but an experiment with REXX showed that it was just too slow for the purpose. Someone did suggest Perl (version 4 was on the systems). I took one look at the couple of example scripts that were available and rejected the idea out of hand as "write-only line noise".

    In my defense, I'd never seen Perl before and none of the unix people put up much of an argument. I'd also put a considerable amount of effort into learning awk etc. in order to get the (working) tool to where it was, I was kind of proud of it.

    When I left the project, it was still tool of choice. The last view I have of the lab is a photograh one of the guys emailed me. Taken at a milestone celebration some months later, there are at least a couple of copyings running on the screens in the background.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
Re: That screwdriver looks like a hammer...
by leriksen (Curate) on Aug 23, 2004 at 05:47 UTC
    I wrote an internal web-based tool to track data entry statistics for a large scanning bureau - anything the OCR wasnt able to correctly identify had to be keyed.

    A late request came in to add support for "benchmarks" - to highlight statistics in red or green to identify operatorsthat seemed to have consistently high or low performance. We also classified documents this way too - so we could track jobs that, regardless of operator, seemed to be above or below expected keying rates.

    Two side-effects of this

    • a fight between the union and HR that this was going to be a tool to sack low-performers - it wasn't intended for that and isn't used that way - supervisors say that when someone isnt performing there are plenty of other indicators aside from keying rates. In fact operators (who have zero knowledge of how the rates are collected or calculated), quickly worked out that keying stats referred to just that - no keying meant no stat. They would key as quickly as possible, then turn to answer aquestion or make a comment, key like the wind, then comment again. I was amazed at how quickly they adapted their work practices to maximise their reported stats.
    • it highlighted almost immediately where a new job was going badly wrong, because it was down at the 10% level - a review of the scanning and operators resulted in a new work instruction, and the job was back on track - the tool went from a simple performance monitor to an active feed back instrument overnight

    use brain;

Re: That screwdriver looks like a hammer...
by ambrus (Abbot) on Aug 23, 2004 at 08:11 UTC
    The extreme example being the lowly paperclip - in one study (admittedly done several decades ago), one one paperclip in 10 actually got used to clip papers together. The rest went to a variety of uses, many of which involve the wire being bent until it becomes a different tool. Or even just mangled as a convenient outlet for a desire to fidget.

    Very true. I have used some paper-clips as screwdrivers. Those were of course paper-clips with a sharp end, like

    ______ [____>_>
    not those with a round end like
    ______ [____)_)

      You should submit these to the Pine maintainer as indicators of emails having attachments... ASCII 7 compliant graphics...
      My "Demotivators" calendar is hanging from a hook made from a large paperclip right next to me.
Re: That screwdriver looks like a hammer...
by Your Mother (Archbishop) on Aug 23, 2004 at 08:02 UTC

    I wrote (in perl) what I thought was a quality assurance tool to see how many gift certificates were being used by customer service reps and what size and in which cases. It wasn't an assigned task, but it was related to my group and with perl it was the kind of thing that could be done in an afternoon so I did.

    While my goal had only been to ensure service quality, it ended up, as you probably already guessed, turning up quite a bit of fraud. A few service reps giving away thousands of dollars worth of gift certificates in total to friends/family.

    A small batch of firings ensued.

Re: That screwdriver looks like a hammer...
by Zaxo (Archbishop) on Aug 23, 2004 at 07:34 UTC

    Not that I wrote it, but isn't Perl itself like that?

    I think there's a long history of features being used in unexpected ways. Typeglobs come to mind.

    After Compline,

Re: That screwdriver looks like a hammer...
by davido (Cardinal) on Aug 23, 2004 at 04:53 UTC

    On a cynical note, how many formmail type scripts (by various authors) have unwittingly become spam mailers instead of "Contact us" forms?


Re: That screwdriver looks like a hammer...
by CloneArmyCommander (Friar) on Aug 23, 2004 at 16:52 UTC
    Hahaha :), I know this wasn't the point of the meditation, but the paperclip thing started to remind me of the days when I was stuck using the old Macintosh computers. They were so messed up that we had to retrive floppy disks by straigtening a paperclip and inserting it into the hole below the floppy device :). Memories :).
Re: That screwdriver looks like a hammer...
by perlfan (Vicar) on Aug 23, 2004 at 16:20 UTC
    LOL. Great success story, however I thought it was going the other direction.

    I've found that most of my stuff has not been used as I intended, but mostly because it is mostly *not used* at all - not because people are dumb, but because they are lazy and don't want to pick up a new "wrong" tool.

    Nothing annoys me more than creating something that is not even evaluated - I doubt I am the only one with that experience, though.

      You're not the only one with that experience.

      I work as part of a team that is responsible for scores of operational activities, including "ad-hoc" monitoring of application memory use in emergencies. We were recently tasked with doing a daily check of an application's resource usage, and restarting it when usage reached a certain threshold. Manually executing this task took our best (brightest, fastest, most accurate) people 20 minutes. Yesterday afternoon I took a couple of hours to write a Perl script that does this task in 20 seconds. Everyone in the dept knows about it. Do they use it? No.

      I'm confused about it -- this is a case where no tool existed in the first place. Now, a tool exists that gets this repetitive, annoying task out of the way 60x faster, and it's ignored. Humans are strange beasts :-)

      I'm on *that* wavelength. I recently built a shutter controller to ship with one of our spectrometers. I also built a small test box to determine if any given problem might be with the controller or with whatever device was driving the controller. I heard later that there was some problem which our "customer" spent half a day to discover that the controller was OK and the problem was elsewhere. The tester would have isolated the error in less than a minute, but they couldn't be bothered with finding the tester. Oh well.

      (so many nodes and so little time ... )

      I wrote - way back - a quick and dirty little program to find people who had attached their own hubs/switches to the network. I have just started dabbling in Perl and SNMP, so the first few scripts were quite horrible, inefficient, and (worst) similar to each other.

      Several years later, the tool is still in use, but has a built-in Web interface (that needs to be re-written to use CGI;, now that I know how), many different kinds of reports, much better SNMP handling, and a built-in arbitrary MIB query tool for the desparate debugger (usually me).

      Naturally, only one of these functions is actually used by any number of people, despite the fact that I hear them whine every day about not having this piece of info or how the ports are set on xx device. "~ has done that for years," I say. Blank stare. Sigh.

      At least there are two guys who use some of the more interesting features on a regular basis. These two understand 'intelligent laziness'. Sure, you *could* do it manually, but what's the point, especially when you need to do it accurately, and you need to do it 30 times?

      Ironically, the best thing to come out of the whole project - aside from my drastic knowledge gain in Perl, SNMP, and several other related topics - is that a lot of the app is written as modules. Originally, this was just to speed the thing up, since modules (and SelfLoader) were a great way to only load and interpret the code for the report I wanted. But later, I realized that several of the modules became what modules are meant for: I'd built a fairly functional API!

      Since then, I've used those modules (and CGI, and...) to create several other Web apps (and cron jobs), and those for some reason are much more appreciated. Go figure.

      The whole thing is due for another rewrite. I still do a lot of things manually that Net::IP, Net::IPv4, CGI, several other modules do better and faster. But it was certainly fun!

      If anybody wants to play with the app, it's called 'JScan' (named after me, originally, since at first I didn't anticipate that others would use it), and is at JScan.

        I think it would be worthwhile to change the name (before it spreads too far) -- for most people with anything close to a current understanding of software, an initial "J" in an app name tends to imply "written in java" (which, for me at least, would tend to steer me away from looking any closer at the app, unless I really had to).

        If I had seen the name first, then learned that it was written in Perl, I think I'd be disoriented for a little while...