Credit: Psion Workabout Pro"I'm still a student," writes Rob J., "but recently I completed an internship for my Computer Science courses with a manufacturing company nearby. The company's process machines were totally computerized and their IT department consisted of the Network Administrator and the Software Developer (fortunately 2 different people), supporting the entire IT needs of the company of nearly 200 workers."

"As a developer / admin intern, I caused my share of disasters; yes, I managed 'sudo rm -rf /*' on the Linux server that wasn't backed up and I broke another two Windows boxes using SysPrep, all on relatively small servers that weren’t that difficult to rebuild, thank goodness. Overall, despite these disasters, I felt that it was a good experience and I learned more after cleaning up after the systems that I broke."

"These paled in comparison though to what was simply known in the company as 'The Stock System'."

"Like many manufacturing companies, the firm kept track of the stock in their warehouse using a custom ERP system, but theirs was special. Between job.asp, job_new.asp, job_new2.asp, job_donotuse.asp, job_kevin.asp and so on, nobody had a real good feel on how it worked, or how it worked at all for that matter. True, there’s always the system documentation for reference, but so far as the Stock System was concerned, this was synonymous with the source code."

"Then the word came out to upgrade the system from ASP to ASP.NET for support reasons and to help maintain overall sanity."

"My supervisor worked on the desktop stock management app and I took up development of the handheld RF scanners - Windows CE devices with barcode readers used to manage stock items and scan materials between the manufacturing floor and the warehouse."

"Things were going great until some of the users were reporting occasional inconsistencies in item quantities."

"After some searching, we figured out how the different categories of in-stock quantities had to mesh for the system to run smoothly, but what we didn't know was why this was happening. My supervisor dictated some pseudo-SQL to me that would update all quantities for all materials across all the required databases - a four-step process, which involved getting a list of materials, iterating over them to discover how many reels we had, sum up the quantities and then update the tables accordingly, and, like magic, it worked! Inventory quantities aligned and all was well again."

"It was about this time that I hatched, what I thought to be at the time, a 'brilliant' plan – what if I could proactively fix inventory inconsistencies? After all, it the scripts were written to leave good data alone."

"So, I turned these four SQL statements into a tiny command-line app that, when run, would end up processing several thousand records at each stage. It worked, so I set it up as a scheduled task running on the master database server, running every five minutes and marked the issue temporarily resolved until I located the bug."

"Over time though, my priorities shifted. I was taken off the handheld system, which was working fine with my 'short-term fix' in place, and given other work to do which, unfortunately never gave me the chance to fix the app to work properly. I've left the company and a new intern is occupying my desk, but I have no doubt that the little app I wrote is still running on the server.

"Every five minutes."

"I wonder what will happen, years in the future, when someone takes the system apart for an overhaul and discovers the 'quick fix' still running."

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