Here’s an old essay I wrote back in 1998, reproduced for no good reason. The story is completely true, and the client in question was Pfizer.
Adventures in Consulting, Episode 1
Sometimes as a consultant, you make seemingly innocent suggestions to your clients that end up
haunting you for months. For example, I was working on a groupware project, and the client wanted usage reports to see how the application was being utilized.
I innocently suggested that we could beautify the reports with some simple graphs generated using Java applets. The applets came prepackaged with the middleware we were using, and setting them up with dynamic data was trivial. They had drop shadows, nice legends, and all sorts of other eye candy, and the performance was pretty darn good, all things considered. The client was impressed. This is why they pay the big bucks to consultants for these types of things.
Then, I noticed a problem. The client’s site is standardized on Netscape Navigator. Netscape Navigator won’t print Java applets. Faced with the prospect of being unable to print out these eye pleasing graphs, the client was nonplused. Naturally, with our solution crumbling before our eyes and the deadline staring us down, the project shifted into panic mode.
It was too late to pull back, what was once a feather in our cap was swiftly looking like a black eye. The graphs had become a requirement. We were redeemed by a third party product that was only going to cost the client another thousand bucks. It was another suite of Java graphing applets, but this one came with a funky client-server application that allowed you to click on a button and create a duplicate of the page with a GIF instead of an applet.
Sure, compared to the single Java applet, this was a bit more complex. It required two Java applets
instead of one, and oh yeah, you have to run a separate server process on the Web server that will generate the GIFs dynamically. Naturally, these additional components hurt performance a bit, but
hey, it worked, and when you start throwing in requirements as the project progresses, these things happen.
After we demoed this fine working alternative, there were questions about the speed of Java, firewall
issues with the client-server applet, and general issues with performance. Panic again reared its ugly head.
It’s not like we were out of alternatives. Remember, I’m a consultant. The Java applet suite
shipped with yet another utility, one which will run a Java applet locally and save a snapshot as a GIF. We could just create a snapshot of each report nightly and let the users go to static HTML
pages. This seemed to be a fine solution; at the low price of slightly stale data we’d get great performance and something that works in almost every single browser. The verdict was rendered —
the graphs must be generated using realtime data.
At this point, you may think that I was scrambling, but it takes more than a few serious setbacks to
put me out of the game. Never mind that the deadlines had come and gone, and our new deadline was a couple of short days away; failure was not an option. In the shower one morning, I had an epiphany. I
would write a Perl CGI script that would figure out which report a user wanted (and whether they were allowed to see it), which in turn would call the Java utility, which would call the script that
would dynamically render the page and graph, and save the snapshot; and then redirect the user to the new page that was created on the fly. Brilliance.
Sure, it sounds a bit complex, and you might think that there are performance issues with a Perl
script that launches Java which in turn loads a scripted web page, writes the page to new HTML and GIF files, and then sends the users to that page, but hey, that’s the price you pay for long lists of
convoluted requirements. With a devilish gleam in my eye, I delivered my newest Rube Goldberg creation to the product manager, proud that I had managed to actually meet every single requirement
of the project, with no tradeoffs (except for perhaps a small performance hit).
Sitting in my cube, getting started (late) on my next project, I was jarred by the very project
manager to whom I had just made the delivery. “It doesn’t work.” What do you mean, I asked. Of course it works. “The page never comes up.”
Innocently I responded, “How long did you wait?”
Adventures in consulting (from June 30, 1998)
Here’s an old essay I wrote back in 1998, reproduced for no good reason. The story is completely true, and the client in question was Pfizer.
Adventures in Consulting, Episode 1
Sometimes as a consultant, you make seemingly innocent suggestions to your clients that end up haunting you for months. For example, I was working on a groupware project, and the client wanted usage reports to see how the application was being utilized.
I innocently suggested that we could beautify the reports with some simple graphs generated using Java applets. The applets came prepackaged with the middleware we were using, and setting them up with dynamic data was trivial. They had drop shadows, nice legends, and all sorts of other eye candy, and the performance was pretty darn good, all things considered. The client was impressed. This is why they pay the big bucks to consultants for these types of things.
Then, I noticed a problem. The client’s site is standardized on Netscape Navigator. Netscape Navigator won’t print Java applets. Faced with the prospect of being unable to print out these eye pleasing graphs, the client was nonplused. Naturally, with our solution crumbling before our eyes and the deadline staring us down, the project shifted into panic mode.
It was too late to pull back, what was once a feather in our cap was swiftly looking like a black eye. The graphs had become a requirement. We were redeemed by a third party product that was only going to cost the client another thousand bucks. It was another suite of Java graphing applets, but this one came with a funky client-server application that allowed you to click on a button and create a duplicate of the page with a GIF instead of an applet.
Sure, compared to the single Java applet, this was a bit more complex. It required two Java applets instead of one, and oh yeah, you have to run a separate server process on the Web server that will generate the GIFs dynamically. Naturally, these additional components hurt performance a bit, but hey, it worked, and when you start throwing in requirements as the project progresses, these things happen.
After we demoed this fine working alternative, there were questions about the speed of Java, firewall issues with the client-server applet, and general issues with performance. Panic again reared its ugly head.
It’s not like we were out of alternatives. Remember, I’m a consultant. The Java applet suite shipped with yet another utility, one which will run a Java applet locally and save a snapshot as a GIF. We could just create a snapshot of each report nightly and let the users go to static HTML pages. This seemed to be a fine solution; at the low price of slightly stale data we’d get great performance and something that works in almost every single browser. The verdict was rendered — the graphs must be generated using realtime data.
At this point, you may think that I was scrambling, but it takes more than a few serious setbacks to put me out of the game. Never mind that the deadlines had come and gone, and our new deadline was a couple of short days away; failure was not an option. In the shower one morning, I had an epiphany. I would write a Perl CGI script that would figure out which report a user wanted (and whether they were allowed to see it), which in turn would call the Java utility, which would call the script that would dynamically render the page and graph, and save the snapshot; and then redirect the user to the new page that was created on the fly. Brilliance.
Sure, it sounds a bit complex, and you might think that there are performance issues with a Perl script that launches Java which in turn loads a scripted web page, writes the page to new HTML and GIF files, and then sends the users to that page, but hey, that’s the price you pay for long lists of convoluted requirements. With a devilish gleam in my eye, I delivered my newest Rube Goldberg creation to the product manager, proud that I had managed to actually meet every single requirement of the project, with no tradeoffs (except for perhaps a small performance hit).
Sitting in my cube, getting started (late) on my next project, I was jarred by the very project manager to whom I had just made the delivery. “It doesn’t work.” What do you mean, I asked. Of course it works. “The page never comes up.”
Innocently I responded, “How long did you wait?”