Again, Samantha sat in the darkness, with only the pale light of her laptop to illuminate her surroundings. Again, she was hunched over in concentration.
She leaned toward the computer and peered at the alien script through narrowed eyelids. It was a symbolic act, an expression of her focus more than an amplifier of it.
Kramer Code had struck again.
It had become a constant in her life.
On the phone, earlier that night her husband remarked that Kramer got more of her attention than he did. The back of her mind recognized he was only half joking.
Samantha had confirmed and rebutted in four words: "Attention? Yes. Affection? No."
The truth of it stung her, though.
Why should she have to stay late because he can't seem to get anything right?
Why did he always check in just before a release?
Why did none of the tests ever catch what he was doing?
The team had become so tired of it, that they turned on pull requests. The branching made things a lot slower but they hoped that requiring a certain number of approvals to merge might help.
Somehow Kramer always got around it.
Usually, the approvals came from another office in another part of the country or even on the other side of the world. Sometimes, Kramer bamboozled a manager into granting him a variance to let him merge something that was an emergency.
As with most of Kramer's code, the change was nearly irreversible. You could go forward, meaning fix what he had done, but you couldn't go backward.
In this case, as was most of the cases, the code misused some data fields, redefining their meaning in the process.
Reverting the Kramer Code would produce an application that was still broken because the old version of the application couldn't use the new data and there's no easy, automatic way to reverse the change to the data.
Kramer had left Samantha between a rock and a hard place: fix the code or fix the data.
There was no "go back to green". Not for the customers who failed to back up before updating, which is most of them. Not for the customers who want to keep any of the data they have collected since, which is the rest.
Kramer Code was usually just hard enough to deal with that she could crack it but, this time, she was at a loss. It looked, to her, like Kramer had created irreparable data loss.
The only thing Samantha could imagine was to fix the code, create a space for the lost data, and create some kind of migration utility that allowed customers to merge the data they had lost out of a backup.
That was the path of least destruction.
Samantha fired off a note to Fred. Without a body, the message read "Should we forcibly back up before every update?"
She let her mind relax and her focus slackened. Idly, she clicked around, bouncing from class to class. She was thinking but not really about what she saw.
Then she saw something that snagged her attention.
It was a little class called DataTransformMediator. Something kind of strange. Without drilling into the classes to which it delegated, it appeared to copy data out of some entity objects and into a malleable document which would be stored in a non-relational database.
What caught Samantha's eye was that the mediator in question seemed to be coordinating preservation of the exact fields she thought Kramer had destroyed.
She was already VPNed into a client's network, so she opened up their DocumentDB instance and searched for the records related to an affected entity.
"I'll be damned..." she said. "Gotcha."
She minimized the virtual desktop, exposing Visual Studio and started creating a new utility. One that would clean up the affected document databases, repair the affected structured databases, and rollback the Kramer-affected deployment all at one time.
A blinding glare flooded through the window from what appeared to be a yellow ball of hellfire snuggled between two gigantic pines.
"Morning," said Samantha. "Guess I'll get to it."
