Stan arrived one morning to find his boss, Monty, typing up a storm. This meant two things: a horrible spec would land in Stan’s inbox by the next morning, and that spec would shoehorn in a database where none belonged. Monty was a database “expert.” There was no problem his weighty and ill-performing hammer couldn’t nail. During Stan’s first year on the job, he had implemented everything the way Monty described, because he hadn’t known better. Now more knowledgeable of the company’s system, he yearned for an opportunity to do something properly.

In his inbox, Stan found a copy of the customer request that occupied Monty. It asked for two existing ASP.NET applications to be hooked up to one another: a pleasant surprise. This is a perfect case for a simple web service, Stan thought, and since they’re using .NET, WCF is all we need.

There was no possible way Monty’s touch would pollute it. He didn’t know the first thing about .NET. For the first time since getting hired, Stan imagined having some say in the implementation, like a real developer. Finally, a project to be excited about!

The next day, Monty’s spec landed in Stan’s email. Stan opened it not with trepidation, but the detachment of a coroner peeking under a sheet in a morgue. He uncovered a 45-page beast defining an “extensible database-driven IPC framework.” It was difficult to follow, but it appeared to be a tortured re-invention of web services. It barely mentioned either of the apps in the customer’s request, because it was meant to hook any of their applications together when the need arose.

The design called for 11 database tables to juggle transaction metadata (application sending, application receiving, timestamp, user ID, and other trivia) and application data (all to be converted to strings and stored under generic fields named Column1, Column2, ColumnExtension, ColumnField3, etc.). When one application wanted to send a message to another, it had to send all the session/message metadata to a stored procedure. The single procedure call accepted 75 parameters, mostly optional. A similar stored procedure allowed the sender to attach its application-specific data. For an application to receive messages, it needed to call SP_CHECK_FOR_MESSAGES_POLLING_PROCEDURE and pass in its unique PK_INT_APPLICATION_IDENTIFIER value. When it was done with a message, it then called SP_MESSAGE_TRANSACTION_COMPLETE_PROCEDURE to clear the message from its “inbox”. Monty’s system would then move all the data for that transaction to a set of log tables that mirrored the production schema, but didn’t have any referential integrity enforced.

As Stan gaped at his computer screen, he heard Monty’s self-congratulatory gushing behind him. “I’m very excited about this. I want us to be using this for everything!”

“Everything?” Stan battled nausea and the chill hand of Braindeath inching up his spine, and shrugged them off. It was time for him to assert himself, show he was no longer the office n00b with no ideas of his own. “This approach is… interesting, but it’s not actually necessary to use a database for something like this,” he said.

Monty let out an incredulous laugh.

“There’s something in the .NET framework called WCF that would let us do this,” Stan plowed on. “We’d just have to write a few-”

“No, no good,” Monty said with authority, although Stan knew if he asked Monty what “WCF” stood for, Monty would flounder and change the subject. “We’ve been having a lot of problems with the debugability of our system lately. We need to see what’s going from application to application, who’s sending it, and when- and we have to store it all somewhere safe.”

“But, there’s lots of tools for debugging WC-”

“Please implement the system as I have specified.” Monty’s tone brooked no further objection. He walked away, ensuring he’d have the last word.

Battling dread at every turn, Stan plodded over the course of weeks to put together a shoddy prototype. Errors were rampant as there was no good way to enforce datatypes or synchronicity. Building in such precautions where possible made the behemoth even slower than it already was, and there was still no guarantee it would always work as hoped. Meanwhile, Monty’s inept communications with the customer resulted in sweeping change requests. His brainchild mutated day by day into a hellbeast with a now–64-page spec, spanning 14 database tables.

Stan reached his limit. His final recourse was David, Monty’s boss, who touted an open-door policy. He arranged for a meeting with David and explained the situation.

“Not only is it the wrong approach, it’s also not what the customer wants. I could’ve had this done weeks ago if we’d used WCF, and Monty would’ve had all the debugging and tracking he wants,” Stan concluded. “I don’t think it’s too late to switch, but Monty just won’t OK the idea. Is there any chance of explaining this to him?”

David sighed. “I get this a lot.”

Finally! Stan thought, feeling the heady rush of vindication.

David paused for a moment, and assumed the faraway expression of a sage passing down hard-earned knowledge. “Stan? Monty… has his quirks. Sometimes he’s going to ask you to do stuff that may not make a whole lot of sense. I need you to go with the flow and trust that everything will work out. He’s been here since the beginning. Our system is his baby, and he knows what’s best for it.”

Stan knew what was best for his sanity. He went back to his desk without a word of protest and, after an hour of silent contemplation, got up and walked out the door for the last time.

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