Christian P felt kind of bad. His company had just been awarded a contract to take over in-house software development at a fairly large underwriting agency. Not only would six developers be laid off immediately, but the remaining three would be responsible for transitioning their replacements before getting laid off. On Christian's first day, he was prepared to be met with anger, sadness, resentment, hopelessness, and even hatred. But there was none of that; instead, it seemed as if the outgoing developers had a feeling of relief.
After his first day of training, Christian no longer felt bad for the laid off employees. In fact, he was a bit envious of them. The system that they had been maintaining was best summed up in a single world: miraculous. Not "miraculous" as in, an amazing suite of business applications that transformed productivity and caused profits to skyrocket. I mean "miraculous" as in, surviving after being shot twelve times, thrown from an airplane, landing on a rosebush with a hornets nest inside, dragged out to the river by a bear, carried downstream over Grade VI rapids, and spit out to the ocean for a three-day tread. Because that pretty much describes what their system went through. It also explained why none of the developers were interested in working as contractors for 50% more than they were making as employees.
The core of their system was the Processing Engine, a complex application that was responsible for communicating with loan brokers, analyzing underwriting applications, creating insurance policies, and all sorts of other things. It was developed a few years ago by the Ultra-Dedicated Programmer, a fellow known to put in 80- to 100-hour weeks on "his" Processing Engine. After declaring that his system was "perfect," the UDP abruptly quit, telling everyone else to just "tweak it as needed." The other developers spent the next year or so "tweaking" the system and trying to get it to function as it was supposed to.
One of the first things the outgoing developers mentioned was that the Ultra-Dedicated Programmer designed the system to be multithreaded. For whatever reason, he was never able to figure out the source of some rather obscure multithreading errors through the system, so he devised a "work-around." A Thread Manager was created to allow only one of the application's threads to run at a time. When a thread completed its task, it would then have to notify the Thread Manager so that the next thread in the queue could be reanimated.
Despite being an unattended, non-interactive system application, the Processing Engine was not run as a Windows Service. It ran as a GUI application. A cute GUI application. Really, it kind of looked like Winamp and had all sorts of greenish and reddish decorations over a black background. Every part of it was animated, with wave graphs, "LED" lights, bar charts, and all sorts of other things to indicate what the application was doing. At least, that's what everyone assumed they were for; the graphics provided no indication as to what they were measuring and none of the developers cared to look.
Curiosity got the best of Christian and he decided to dive into Processing Engine's source code. He found a unit named "ukittscan" and decided to take a closer look. This is what the first few lines looked like:
After I got the new Swag-snippets and saw how to make components for
Delphi, I just made this one for fun.
You all still remember Knight Rider with his car, KITT... Well, at the
front the car had a scanner... I made it as a component...
Author: Martijn Tonies
That's right, it was a component downloaded from the Internet, made by a guy who just played around with Delphi, and thought this component might interest others. Well, it did, and is now an integral part of an application that underwrites tens of billions of dollars each month.
Congratulations, Martijn! Your very first component has proven itself flawless in a mission-critical server application!