Photo credit: 'digicla' at Flickr Tyson wasn't used to 8:00am meetings, let alone meetings with the not-so-technical-even-though-their-name-implies-it Application Auditors on the dimly lit 32nd floor. Arriving fashionably late at 8:06, he was struck by how many suits were in the meeting with him - and he'd again opted not to shave.

The middle-suit seated across from him began, "Tyson, let me cut to the chase - there are some serious flaws in your CASTLE system."

"Humph...Exactly what do you mean by 'flaws'?" Tyson replied indignantly.

"Flaws that are costing our company time and money. We're at a point where developers in the different business units have to add extra time to their estimates to code around flaws in retrieving information from CASTLE. As a first step, we've scheduled a source code and database review to--"

"Waitaminute - hold on here," spitted Tyson, "No, No, I've...been down this road before! CASTLE just had a database table review! I'll fight it! It'll end in disaster, you'll see!"

"Complain all you want - You have no choice or say-so in this"

Rise and Fall of CASTLE

Tyson was pissed. His CASTLE was under attack. Didn't the fools who were pointing out all these so-called "flaws" realize that it was the greatest and most powerful electronic medical records system ever invented?

20 years ago, he'd have been right. Thanks to his bold choice of using MUMPS as a database and hand-coding all database interaction (bypassing the API that would be invented in a few years), CASTLE was blazing fast and ran with miniscule memory. It allowed his system to support screen-driven data entry when most people were still using paper records.

The system grew fast and added lots of features, thanks to extensive cut-and-paste code and avoidance of requirements gathering, modeling, planning, documenting or writing functions that can do more than one thing. There was a slight hiccup in the 90s, when Tyson decided that everything had to be put on the web. Large quantities of code had to be rewritten, and the five programmers assigned to this task have been working continuously on it for the past decade (it's still not done). Since these were mostly the same programmers who wrote the original non-web CASTLE, the new code is pretty much copied-and-pasted old code where, instead of printing text and VT102 codes, it prints HTML. Most of the old code wasn't reusable since it usually printed as it retrieved data.

As time and development trudged along, Tyson began to tune out complaints, dismissing them as grumbling from malcontents who'd hate any system they'd be given. However, even common users of the system were starting to notice that development was slowly grinding to a halt. Functionality couldn't be changed since not even the developers knew what code updated which data in every case and there was the fear that even the smallest change could break the existing data structure. Eventually, after a broken contract involving a refund of a few hundred thousand dollars to a client who waited three years on a system that was promised, Tyson was demoted.

The Review

Now, a review of the database found hundreds of tables that were unused. Despite his dire warnings, 60 were easily removed without incident. Another 95 were scheduled for review. Tyson's response was to insist on being involved in the review and to be the one to actually delete stuff, and then hope everyone would forgot about it. Why clean up the database? Is having more data a bad thing?

The next straw nearly gave him an aneurism. An automated review of the code found over 1800 source code files that were completely unused. A conservative double-check revealed that at least 1300 hadn't been run in over 3 years. Despite his objections, these 1300 were checked into CVS as 'deleted' (they're still retrievable if someone needs them). This was well over half the code in the repository. Of the remaining half, an estimate was that over half the functions defined in those files were also unused.

They'd stripped Tyson of his position, his code, and most importantly, his power. At this point, Tyson decided that he had no choice but to fight back.

Tyson's Revenge

Steve X. as you may recall as the hero from this story's previous installment, didn't work on the MUMPS-based CASTLE system, but he did work on the systems that interfaced with it. One of these being the "Welcome" screen that showed the user the last time they'd logged in.

One morning, Steve had received a support request ticket stating that the value of the last login date hadn't been updated in about a week. While not critical, this was moderately annoying to the more anally retentive (and influential) users and as such, got escalated as a top priority item.

Steve's analysis showed that there was a change to disable the recording of the "last login" date roughly a week ago. After narrowing it down to a change committed by none other than the infamous Tyson (who didn't tell anyone), Steve reported it to his manager.

Management determined that since Tyson broke it, Tyson should fix it. Steve X followed up in a couple days and found that it now reported the most recent time you logged in. As in... 3 seconds ago. After pointing out to the management that it's not terribly useful to know when you just logged in, Tyson was told to fix it again.

A few weeks later, Tyson changed it such that it simply would hide the "last login" if it was less than 10 minutes ago. So, it still doesn't tell you that someone logged in as you at 11:00pm last night when you weren't here, but at least 10 minutes after you log in, you can go back to the 'Welcome' page and see that you logged in 10 minutes ago.

Errors? What Errors?

A complaint surfaced that some of Tyson's apps were generating JavaScript errors. It would have been simple to fix these errors, but Tyson couldn't be bothered with mundane issues like this. Instead he disabled the error reporting mechanism. For everybody.

At the same time, he noticed that another of Steve X's apps (a system that allowed you to bookmark pages and jump to them quickly) wasn't being loaded in the place he would liked to have seen it being loaded. Instead, it was loaded right before HTML headers were printed. So he removed it. Naturally, he removed both these things without telling anyone.

A few days after these were committed to production, complaints started coming in that the hotkeys were broken. It took a few days after that for someone to assign the ticket to Steve. This time, it only took half an hour to find the change that was made and revert it.

Confrontation

Soon after Steve applied his fix, management decided that the time was right to have a meeting with Tyson to discuss his recent...performance. However, before any of the managers could start, Tyson started straight into the conversation.

"Listen, we're striving for quality, right?" Tyson started with a cocked eyebrow, "Well, my fixes were to REDUCE the amount of GARBAGE that users don't care about and things that just implemented wrong."

"But Tyson, listen, you're the one breaking CASTLE's functionality, you're -"

"I have been working on this system for the past 20 years! NOBODY knows CASTLE better than me.  When you have my level of knowledge, only then we can discuss what is and is not breaking the system."

In the end, Tyson agreed that whenever he would make any ad hoc changes to any part of the system that he would send out a broadcast email stating what he did and that he tested it. Many were not surprised the reason why Tyson agreed was because he was able to show off how great his system was.

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