Updates to the decades-old internally-developed bank management application had gone as smoothly as they could. No major issues moving from text screens on dumb terminals to text screens on Windows 3.1 to a GUI frontend in Windows 95. And now it was time for another major update; to give it the best GUI ever to appear in a decades-old internally-developed bank management application! And thanks to some good planning, respect for standard software development procedures, good tools, and a happy environment, the upgrade was going great!
That is, until the killjoys at Initrode Business Quotients threw a wrench in the operation. The application was actually more of a multi-application environment, all of which had to be able to talk to one another. As such, IBQ had to update its reporting application to work in the new environment. While their updates had gone almost as smoothly as those for the main application, they'd left out one feature.
The reports were supposed to call out when there was something that required attention. For instance, if someone set up a virus on the computers to bleed out money (like in Superman III), it wouldn't be noticed by the report so this is a terrible example. Anyhow, it was supposed to have a status image next to each report. Green meant good, yellow meant that it's OK but not great, and red meant bad. They dubbed this icon the report's "mood."
Users loved the feature, so Initrode Bank Processing was disappointed to see the feature absent from the latest version. The project manager sent an email to IBQ's product manager to ask about it. It didn't take long for a heated and defensive email back — It was out of the scope of the original directives! Other departments were copied on the email, and soon a huge branching conversation started picking up more and more people. IBP argued that the feature should be in, IBQ argued that it was out of scope. In short, it was "we want dots" versus "dots are too complicated!"
Finally, a manager from IBP demanded an explanation of why it was so difficult technically to include the dots. IBQ said that it was impossible in the new application environment (to display a lousy JPG), and the reasons were too many to explain.
The reply from IBP? "Humor us."
They explained that the application's custom web browser was too complicated and would occasionally stumble over AJAX sites. Which is all well and good, but it's never failed at displaying a single image. IBP responded as such.
IBQ didn't issue a response for several days, until finally:
In order to add an icon into the web page we will need to dynamically:
- Process the report from the database
- Render the icon in memory
- Save the image to the server's hard drive
- Render that image within the web page
- Do all of this on the web site without conflicting with other alerts or users within the file system web site
It will be an extreme challenge to manage the thousands of icon files that will be created in a business day. It will likely cause filesystem corruption and server outages unless we have months to test the algorithms. Placing these images on the pages will clearly be a huge undertaking!
And with that email, the requirement was officially removed. IBQ was off the hook, and could focus on not putting images in their other applications. The technical jargon had flown over the heads of the managers and VPs.
It wasn't long after that that the system was finished and dotless. During its deployment, an IBP developer took a peek at the database. In a procedure called rpt_GetReportMood, the answer was laid out in a long multiline comment:
TODO: Rework the database schema to hold Report mood before getting to the point that it will be a royal pain to implement it.