The First Day of a new job is almost always slow and uneventful. A bit of paperwork in the morning, a quick walkthrough of the system, and possibly a trivial First Assignment. Nick’s First Day at the International Shipping Company (as I’ll call it) was no exception. In fact, it was so slow that it seemed like the First Day would last all week. That is, until a frantic coworker burst into his cubicle.

“Hey, New Guy, do you know anything about SQL Backups?” Before Nick could even nod affirmatively, he continued, “’Cause, the backup on our Tracking Application is failing, and that’s a big problem. Oh, I’m Dave by the way.”

Nick immediately followed Dave to the server rom. With a quick query of physical table sizes, Nick was able to determine exactly what the problem was. The table “TBLWEB00” was several dozen gigabytes and could not fit in the backup set.

Neither Nick nor Dave had any idea what was in that table. Its name – and the fact that it was used by a web application – implied that anything could be stored there and its size implied that everything was stored there. He peeked at the table schema and found something like this: 

TABLE [TBLWEB00]
(
    [ICSROWID] INT IDENTITY (1, 1) NOT NULL PRIMARY KEY,
    [LOGDATE0] DATETIME NULL,
    [URL00000] VARCHAR(500) NULL,
    [QUERY00] VARCHAR(500) NULL,
    [QARG0001] VARCHAR(50) NULL,
    [QVAL0001] VARCHAR(50) NULL,
    …
    [CLIENTIP] VARCHAR(50) NULL
)

A look at the data and it was obvious that the table was used to record page hits, along with referrers, IP address, query string, and really, anything else that’d already in the web server log file along with a few columns of parsed/recoded data. Since the table wasn’t actually being used, Nick was able to drop some columns, a whole lot of rows, and cut the size of the database in half. One question, however, remained: WTF was with that table?

The Legend of Kyle Söze

“Oh, that table,” Dave responded hesitantly, “yeah, that’s one of Kyle’s. You’ll see a lot of that around here. All I can say is just be glad you never have to work with him!”

As it turned out, Dave hadn’t worked with Kyle, either. In fact, no one had. Most knew Söze (as I’ll call him) through his work and everyone knew him through The Legend.

Long before anyone could remember, Kyle Söze was hired to help develop web and desktop applications. Along with “years and years of experience” and a reputation for “making things happen,” Kyle brought along his own, unique way of doing things. The pinnacle of his methodology lay in Database Design.

Design By Kyle

The rules of Kyle’s database design are simple:

  • All identifiers (table names, column names, etc) must be exactly eight characters in length
  • All object names (tables, views, etc) must consist of a three letter type code (“TBL”, “QRY”, etc) and end with a two-digit numeric extension, starting at “00”. The remaining three characters are used to identify the object
  • All tables must have an auto-identifier column named ISCROWID (ISC for International Shipping Company)
  • Constraints (including foreign key and unique) shall not be used and enforced entirely in the UI

TBLWEB00 followed this format to a tee, as did hundreds of other Kyle Söze tables: 

TABLE [TBLISR00]
(
    [ABCROWID] INT IDENTITY (1, 1) NOT NULL ,
    [CUSTNMBR] CHAR (16) NULL ,
    [CNTYSTAT] VARCHAR(100) NULL ,
    [CNTYOFIC] VARCHAR(500) NULL ,
    [CONVDATE] VARCHAR(50) NULL ,
    [INSTDATE] VARCHAR(50) NULL ,
    [DATETRNA] VARCHAR(50) NULL ,
    [DATETRNT] VARCHAR(50) NULL ,
    [DATETRNC] VARCHAR(50) NULL ,
    [CONTACT1] VARCHAR(50) NULL ,
    [CONTACT2] VARCHAR(50) NULL ,
    [CNTEMAIL] VARCHAR(50) NULL ,
    [PHONENM1] VARCHAR(50) NULL ,
    [PHONENM2] VARCHAR(50) NULL ,
    [FAXNUMBR] VARCHAR(50) NULL 
)

TABLE [TBLISR01] 
(
    [ABCROWID] INT IDENTITY (1, 1) NOT NULL ,
    [ISRRECID] INT NULL ,
    [CNTYSTAT] VARCHAR(100) NULL ,
    [TAAGREMT] VARCHAR(50) NULL ,
    [TAAGRECK] VARCHAR(50) NULL ,
    [TTAGREMT] VARCHAR(50) NULL ,
    [TTAGRECK] VARCHAR(50) NULL ,
    ... snip ...
    [CLBILLED] VARCHAR(50) NULL ,
    [CLBILDCK] VARCHAR(50) NULL ,
    [CLINVOIC] VARCHAR(50) NULL ,
    [CONVMEET] VARCHAR(50) NULL ,
    [CNVMETCK] VARCHAR(50) NULL ,
    [SITEVIST] VARCHAR(50) NULL ,
    [SITVISCK] VARCHAR(50) NULL 
) 

... etc ...

Kyle’s coding Practices were just as “unique.” The UI was responsible for enforcing business rules via JavaScript and code reuse was accomplished with copy/pasting. Still, since Kyle “made things happen,” management gave him all the discretion he needed to continue. Who were other developers to question Kyle Söze?

The Usual Plan

With a portfolio of successful projects (as in projects deployed to production), Kyle Söze was not an easy man to discredit. Many young, brave developers tried and failed, losing significant amounts (if not all) of their own credibility along the way. How could anyone rebuff, “I’ve been doing this for twenty years and only have a few hundred success stories, but what do I know? Yes, your way must be right”

One clever developer, however, thought up a plan. If they could get him on a larger project as an “expert consultant” (as opposed to the lead developer), they might just be able to wear him down enough. It was a crazy plan; crazy enough to work.

The Fall of Kyle Söze

To help “accommodate” the “expert consultant”, the project team decided on “democratic” design process.” Any conflicting design ideas would be presented, discussed, and then voted on. Every architect – regardless of his years of experience – would get one vote.

This made for a long and tedious process. Week after week, Kyle would explain the one and only way to solve a particular problem. Hours later, an “alternative” approach would be discussed, voted on, and then approved. Kyle was the only one who would vote for his solution, and would always shake his head and scoff “you guys are wrong, but what do I know, I’m just the expert consultant!”

When they got to the topic of database design, however, Kyle’s reaction was significantly different. When a “relational” model won the design vote, Kyle became infuriated. His way was the only way when it came to databases, and this was a battle he just refused to lose. He threatened to escalate to management but was quickly rebuffed when the project manager reminded him that they had all already decided on a democratic approach. Even more furious, Kyle stormed out of the meeting and left for the day.

Kyle Söze did not show up to work the following day and instead sent an email to his boss and the project manager. It read “I’m quitting. I’ll work my last two weeks if you want, but unless I hear otherwise, I’m not going to be coming in again.”

At the next design meeting, the project manager passed out a copy of Kyle’s email and tried to contact Kyle’s boss to see what they should do. Since his boss was on vacation, he never replied back to Kyle, and no one has ever heard from Kyle since.

Epilogue

All that remains today the great Kyle Söze at the International Shipping Company is a mountain of code and, of course, the Legend of Kyle Söze .

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