Being the consummate IT professional, John took pride in his ability to automate the more regular and mundane aspects of his job. While not everything bent to his scripting will, with the appropriate cmdlets, plug-ins and modules, there were few areas that were beyond his (automated) reach.

But even then, there were still some regularly executed processes that had not yet been touched. Following the crucial "if it's not broke, don't fix it" mantra, John was willing to let these pieces of antiquity continue to have their day until necessity demanded a change. The key being, naturally, if it's "not broke".

Roman worked in the development group one floor up from John. One fine summer day (well...it was summer in the Southern hemisphere. Not so much in Winnipeg), Roman came down to speak with John.

"I've been working on a project that interacts with the files in this process", said Roman, pointing at the print outs of a number of as yet un-migrated .BAT files. "I was wondering if you might be able to walk me through what it's doing so I can make sure that I'm not going to break it?"

The .BAT file in question was moderately complex. The basic functionality was to look in a directory for a specific file, and when the file appeared, send it to a remote destination using PSFTP. Naturally there were also many lines of business logic embedded in the .BAT file along with this simple flow.

"Happy to", John replied before going into a 10 minute recitation of what the different pieces of the process were and how they did their job. After he was finished, John promised (and quickly delivered to Roman) the .BAT files that were used.

The next morning, the unthinkable happened: The script failed!

Instantly suspicious, John asked Roman what he had changed. Nothing, he was told - Roman had just been testing a replacement version of the production program that created the source file on his own PC. In the production environment, the source file for which the .BAT was waiting was created manually, and John's script was rerun. Successfully, as the cynical amongst you suspected.

Then, the next morning, it was déjà vu all over again. The process failed for the same reason: the expected source file was missing.

Roman walked over to John's desk, asking (politely) if there was a problem with the components that created the pieces that make up the source file.

"Well, it's possible", John conceded, while not actually believing it to be true. He checked - no, there were the traces of the component files being created, in the right places too.

"Roman, it's got to be your development work that broke production".

"Impossible! The application uses a configuration file to see which servers and directories to use"

"That makes no sense," John protested, "Can you send me a copy?"

As Roman claimed, the config file was indeed all localized. And yet the development process was using the production config file. Somehow.

When John made this comment to Roman, he was met with a blank stare frequently associated with a confused animal. You know, the tilted-head look your dog does when it's trying to figure out what you meant by 'fetch'. Unwilling to explain to Roman the mechanics behind fetching, John suggested redeveloping the troublesome process in Powershell, completely avoiding the issue. Roman agreed. Or so it seemed.

This agreement was struck on a Friday and problems continued over the weekend with the existing process not creating the file. Skip ahead to the following Tuesday and John had the new Powershell script tested and ready to go.

In consultation with Roman, John suggested dropping the new script into place immediately, but Roman resisted. He wanted to keep chewing on the problem in his original application. So John (reluctantly) agreed to wait another day.

Another day, another failure. In response to John's email, Roman replied that he had no idea what the problem was. Not surprised by that revelation, John took matters in his own hands. He sent an email to management, saying that a correction was ready, that it had been approved (lest Roman have an excuse to stall longer) and that it should be deployed now, before the upcoming long weekend.

In his reply, Roman insisted that he was still sure that he was very close to solving problem - once he had a chance to really sink his teeth into it. He was close to his goal...close enough to taste it.

Contacting his manager, John shared both his plan (to use the Powershell script), along with Roman's opinion. That being, leave the broken one in, have Roman sign in every day of the holidays to check that it's working and create the file manually if not. And, of course, allow Roman to keep gnawing on the bone looking for the fix.

To John's chagrin, management decided there was less risk going with Plan B. ...B for bone, that is.

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