Batch of Trouble

Ben had already been with the University for a few years when Dave joined the team. At some point during the interview process, Dave reached the conclusion that he was here to modernize the team. As a result, he started on a Tuesday, and by Wednesday was telling everyone how he would do their job.

Dave strutted from desk to desk, playacting the highly-paid consultant. In reality, he was here to take over the student enrollment system from Ben. Ben had inherited it from Carl, who had inherited it from Bob. A whole chapter of begats was required to trace the roots of the system. It was mostly implemented in simple batch scripts, and it mostly was driven by simple text or CSV files. It wasn't a terribly pretty system, but it did have a few very important features:

It worked.

It didn't require much maintenance.

It was thoroughly documented and well understood by the support team.

Since it didn't require much maintenance, and since Dave could only stand around pretending to be clever for so long before he was bound to stub his ego on something, he had some free time. During one block of that free time, he said to himself, "Batch files? How quaint. I can do better." Dave decided to show some initiative, and he fired up a BPM tool and went to work reimplementing their software in it.

Spring turned to summer, summer to winter, and someplace in there the fall semester got started and nobody paid much attention to anything as they handled the new batch of enrollments. Ben kept a vague tab on Dave, but the less time spent he spent with Dave, the lower the chance of Dave having an "unfortunate" accident. Everything seemed to be running smoothly, and it was best not to mess with it, Ben thought.

After two long years, Dave was ready to unleash his creation on the world. He demoed it, installed it in production, turned off the old batch files, and congratulated himself on a job well done. Fifteen minutes after that, he quit and went off to join a new startup in the incubator run by the University. The only things he left behind him were the new system and a 100-byte text file "documenting" it.

For a week, the only thing anybody noticed was that it was much easier to do their jobs without Dave offering them "advice". And then something broke in the enrollment system. It's difficult to say exactly what went wrong, since the output was simply, "Error
". No one understood the system, so management called Dave. Out of the goodness of his heart and a $200/hr consulting rate, Dave logged in and fixed the problem.

The fix was less a fix and more a "create entirely new problems", and so Ben decided to take a crack at fixing it. The design was neatly modularized, in a way that completely defeated the purpose of modularizing the system. Each module ran in linear sequence, and if one failed, it just exited, without even attempting a clean-up. The next time the scheduler kicked it off, it would start over at the beginning again. Each failure added new errors to the datastore, and it didn't take long for the accumulated errors to start corrupting everything from the user accounts, printer queues, and eventually the finance system.

In a scene out of a crappy romantic comedy, Ben eyed the slick-looking but high-maintenance girlfriend left behind by Dave. Then he turned to the homely-but-sweet high-school sweetheart he had known for years- the batch scripts. And as the schmaltzy music swelled, Ben knew that the batch scripts had everything he had always wanted. He killed Dave's system and turned the batch scripts back on. After a little data cleanup, everything was back to normal.

Almost everything. It seems that things weren't going so well at Dave's new job. A month later he called, hoping that they might need a little more consulting help. "I've got a lot of free time, now," he said.