It's still a holiday weekend in the US; after playing with fireworks yesterday, most of us have to spend today trying to find the fingers we lost. There are no fireworks in this classic story, but there may be some karma… Original --Remy

When Kevin landed a job at Townbank in the late 1980s, he came face-to-face with the same thing that thousands of newly minted developers had encountered before and since – there is more to being a corporate programmer than just writing code – there’s the process.

Second only, perhaps, to the strict rules commanded by the world’s religions, the process keeps the code consistent. Glory to the process – praised be the process - the process is good, the process should always be followed, and above all, the process is good for you!

For nearly everybody, the process isn’t all that bad. It just takes some getting used to. Fill out a form, get a sign off, file the test plan, write a build document - all in a day's work. However, as Kevin would soon find out, at Townbank, there were some processes both veterans and new grads alike couldn’t adjust to.

The Shiva Factor

Kevin’s first assignment was to work within a group involved with Townbank’s IT department’s largest project to date - their huge migration from their aging mainframe to a row of shiny new VAX systems. On paper, the process looked good - consultants met with the business to identify which systems would be migrated, specs would be written, developers would be assigned, QA would confirm that the new system worked like the old one and the code would be promoted into production.

When the project managers first set up the process, the expectation was that the extra steps would only ever be responsible for a small fraction of the total cost or amount of time necessary for implementing a feature, and at first, this was the case. However, as the project continued and more environments were finally brought online, Kevin and his fellow developers knew to add an extra bit of padding to their estimates. Officially, the developers called it many names – systems integration testing, server configuration, environment compatibility testing, but only in hushed voices could it be called out by its true name: “The Shiva Factor”

Serious Business Indeed!

Now, it wasn’t that Shiva was an incompetent or inexperienced system administrator – not by a long shot. In fact, at Townbank, when the decision was made to migrate away from the mainframe to VAX, Shiva’s name was at the top of a very short list of individuals who should manage the infrastructure migration and Shiva took his responsibility very seriously and enacted several of his own policies to address what he felt to be loopholes in the process. For example, every morning, before any developers, analysts, and QA staff could sign-in to an environment, they first had to literally sign-in on a clipboard on Shiva’s desk, to confirm their physical presence. Also, feeling that the process did not track developer actions to a high enough granularity, Shiva arranged source control security so that every code check in and promote between environments required a write up with 2 signatures and had to be performed using his user id. At his terminal.

On quiet days, a quick change could be turned around in one day, however, the quiet days were often holidays or weekends. Frustrated developers took their case to upper management arguing that the policies were hindering progress and seemed to be completely useless. In response, management shrugged – Shiva made his case at the beginning of the project – the environments secure and free from cross-contamination by other instances and developer incompetence because, after all, the VAX servers were still very new and even many of the senior developers were not entirely up to speed.

The masses grumbled and cursed under their breath, but rather than rising up and overthrowing Shiva and ending his iron-fisted reign, everybody just kind of sucked it up and moved forward. Albeit annoying, the process continued in spite of Shiva’s efforts, however there was one situation that Shiva seemingly neglected – what if he was unavailable?

Programmers' Little Helper

Though Kevin’s terminal showed that he was on a clone of the Production environment, his tell-tale customer names “Nosmo King” and “Joe Blow” made him realize the he had made a grave error – the application was connecting to the Development environment’s database by mistake and it was to be tested by the QA team later that afternoon. Ordinarily, fixing this was a piece of cake - make a few changes to the config file in the Development environment and re-promote, however, as fate would have it, Shiva was in a day-long meeting and would not be available until the next day.

Hoping that maybe Shiva left his meeting early, Kevin stopped by Shiva’s desk but was met with only his empty chair, however, a detail about Shiva’s keyboard stood out. The letters A, S, V, H, and I all had their letters worn away. Kevin knew that Shiva was drunk with power, but was he so narcissistic so as to type his name in over and over? …or perhaps it was a hint. For fun, Kevin navigated to a command prompt and typed in “shiva” for both the username and password. Expecting Shiva to sneak up on him at any moment, Kevin pressed enter and was shocked and amazed to discover that he was now logged in.

This was amazing. This was huge. Kevin knew he had to find someone to share his discovery with, however, after tracking down and relaying his discovery with one of the gray beards who had mentored him earlier in his tenure, the reaction was not at all what Kevin expected.

As it turned out, Shiva’s username and password combination were a favorite Townbank “secret” that carried over from Shiva’s days as a mainframe admin.

“To keep Shiva from catching on,” the more senior developer explained, “we would play Shiva’s game once every other promotion.”

“Also, for future reference,” he continued,” if you want to avoid getting caught, and ruining it for everybody else, you might want to log in from your own terminal and NOT from his desk.”