As the Database Architect, Daniel always had a pretty good relationship with Gerald, the Application Architect. At least, as good of a relationship as two natural rivals might have. Their backgrounds were very similar – both worked in Oracle and both started programming in C – and they actually saw eye-to-eye on more things than not. Both architects knew which realms they owned – the Application Architect’s was clearly Java and the Database Architect’s was Oracle – but there was plenty of middle ground to dispute.

However, when the inevitable disagreement would occur, they’d resolve their differences as diplomatically as possible and rarely would need to involve the Chief Architect. It was exactly how the Chief Architect preferred it to be: calm, peaceful, and agreeable. And besides, the Chief Architect had plenty of more important matters to attend to, such as board meetings and other executive-y things.

For as long as anyone could remember, the company and its software-as-a-service products were developed in harmony. But then something changed. The Chief Architect resigned.

The New Chief Architect

Although there were plenty of qualified candidates, there was really only one person who would ascend the role of Chief Architect, and that was Gerald. After all, the outgoing Chief Architect was once the Application Architect, as was the Chief Architect before that and before that. It was the natural transition from executer to executive, where one not only needed to see the big picture, but paint it as well.

There was just one problem. Daniel’s new boss and former colleague didn’t become the benevolent overseer that a Chief Architect should be. Instead, Gerald used his newfound title to usurp virtually all decision-making authority from those beneath him and became obsessed with the most technical of technical details.

The tool of Gerald’s micromanagement came in the form of directives: short, almost poetic statements explaining how something should or should not be done. These directives were based on the Chief Architect’s expertise and experience and as such, they were not up for debate. It wasn’t very long before Daniel received his first directive.

Dear Database Architect,

Directive 595 is as follows.

  "Not null constraints give lack of flexibility, more costly 
   evolution, inhibit the use of the database acting as a service 
   to applications and make it an inhibitor to evolution."

As such, please remove from all production databases.

Sincerely,
Chief Architect Gerald

Although The directive was written just as impersonally as the rest, Daniel convinced himself that it was some kind of oversight, and responded to his one-time counterpart with diplomacy.

Hi Gerald,

I know you've been pushing for a lot of change on the Java side
of things, but I can assure you this hasn't been an issue at all. 
These constraints are in-place for a good reason, as it guarantees 
data quality. The only time these constraints get hit is on import,
but that's exactly when we want to see them.

If you have specific concerns, we should discuss... but changing 
this now offers no benefit and introduces quite a bit of risk.

Thanks,
Daniel

It didn’t get him very far. Within a few minutes, the following message found its way to Daniel’s inbox.

Re: Directive 595

Dear Database Architect,

Please refer to Directive 1. 

"A directive is such that all reasonable discussion has taken place 
and as such is not open for debate."

Sincerely,
Chief Architect Gerald

Daniel was upset to say the least. Without saying a word to anyone, he got up from his desk, walked out of the office, and headed straight for the bar. After cooling off, he vowed to polish his résumé and start calling headhunters. Against his better judgment, he checked his work email when he got home.

Dear Database Architect,

Directive 595 Part 2 is as follows.

  "Foreign and Primary Key constraints give lack of flexibility, more 
   costly evolution, inhibit the use of the database acting as a 
   service to applications and make it an inhibitor to evolution."

As such, please remove from all production databases.

Sincerely,
Chief Architect Gerald

There was no point in replying. It took all of Daniel’s willpower not to immediately resign right then and there. Fortunately, he had a two-week vacation starting the following week, so he wouldn’t have to suck it up for very long.

The Two-week Plan

During his time away, Daniel didn’t spend a single second looking at his work email. But he did plan out exactly what his next two weeks at the office would be. First things first, he’d give his notice to the Chief Architect. He toyed with a resignation letter, but instead settled on a simple conversation. And from there... well... it didn’t really matter since he’d be long gone in a short while.

When he arrived at the office Monday morning, he walked straight past his own office and stepped into the Chief Architect’s. As he said the words, “got a sec?”, he saw that only a coat was sitting in the Chief Architect’s chair. That was unusual, as the Chief Architect never went to meetings – they always came to him.

As he sauntered back to his own office, Daniel noticed that no one was at their desk. It was a strange and eerie sight, so much so that Daniel double-checked his calendar to make sure it wasn’t Labor Day or some other holiday. “Oh hey, you’re back,” one of the Junior DBAs said just as Daniel was sitting down, “I take it you haven’t been following email? Everyone’s in the War Room.”

The War Room

In his six years at the company, Daniel had only seen the War Room used twice for its intended purpose: once to implement a mission-critical service after the vendor providing it unexpectedly went out of business, and the other time for a major platform upgrade. The War Room is a fairly large space that becomes incredibly small after cramming in everyone and their computer. No one likes working in the sweatshop-like conditions, but it’s the best way to get everyone focused on a single task.

“Just after you left for vacation,” the DBA explained as they took the elevator to the War Room, “Gerald issued Directive 595 Part 3. Actually, check it out,” he said while pulling out his wallet, “I made this as a joke… but it’s not really that funny anymore.”

The DBA handed Daniel a laminated, wallet-sized card with big, bold letters reading Directive 595. Below it were Part 1 and Part 2, along with Part 3.

Directive 595 Part 3.
  "Sequences  give lack of flexibility, more costly evolution, inhibit
   the use of the database acting as a service to applications and 
   make it an inhibitor to evolution"

“You guys didn’t actually follow that, right?”

“Of course not,” the DBA responded, “but our Chief Architect decided to, erm... how did he put it... ‘dust off his SQL manual and get back into coding’. So, he came in over the weekend and replaced all of the sequence columns with a sequence trigger that basically did the same thing: max value plus one.”

“Seriously!? Would that even work, I mean—”

The DBA cut him off. “Well, it sorta worked, and since he did it directly in production we’re now dealing with the ‘sorta’ part.”

Daniel was about to call him out on the joke, but then they walked into the War Room. It looked and smelled like a warzone: some developers were napping on cots, others were cramped under a table with their laptop, and empty pizza boxes and 2-liters were everywhere.

“So, we’ve been here for four days. Straight. You should check-in with the CTO.”

Day Four

Daniel found his way to the CTO, who was apparently on the 36th hour in his shift. After a brief debriefing, Daniel learned that it all started with a single-character bug in the Chief Architect’s code. On a certain key table, the sequence trigger computed max value minus one. Normally, that’d trigger a primary key constraint violation, but since the Chief Architect had removed those, the table filled up with duplicate data.

Since several other queries and procedures relied on the uniqueness of unique identifier in that table, they too introduced duplicate data into the system. The less unique the unique identifiers became, the more duplicate data entered the system and the more strange things started to behave. And of course, this wasn’t noticed until after a few million new records (and tens of millions of rows across different tables) were added to the system.

But the good news was that they were just wrapping up. The CTO practically begged Daniel to take over and organize the final clean-up. As the only person having had regular, stress-free sleep over the past few nights, Daniel had no problem taking command and wrapping things up. By noon, he told everyone to go home, get a good night’s sleep, and sleep-in if they wanted to.

Day Five

By ten o’clock the next morning, things had mostly returned to normal. Or at least, as normal as things can be after Directive 595. And that put Daniel exactly where he was just two days ago: eager to give the Chief Architect his notice and find a less totalitarian place to work. The only problem was that the Chief Architect was nowhere to be found, though his coat and belongings were still at his desk.

As Daniel pondered what to do next, the CTO unexpectedly popped-in his office and shut the door. “Thanks again for the help yesterday,” he said with sincerity. “I’ll be blunt. Gerald is no longer with the company, and I desperately need you to be our Chief Architect. Even if just for the interim should you not want it long term.”

It was a no brainer, and Daniel was immediately promoted. Later that day, as Daniel was cleaning out papers the former Chief Architect’s desk, he found a hand-written to-do list that included Directive 595 Part 4. Sadly, no one will ever know what Directive 595 Part 4 was going to be.

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