It's a holiday weekend in the US, and I can't think of a better way to celebrate the history of the US than by having something go terribly wrong in a steel foundry. AMERICA! (original)--Remy

Photo Credit: Bryan Ledgard @ flickr There are lots of ways to ruin a batch of steel.

Just like making a cake, add in too much of one ingredient, add an ingredient at the wrong time, or heat everything to the wrong temperature, and it could all end in disaster. But in the case of a steel mill, we're talking about a 150 ton cake made of red-hot molten iron that's worth millions of dollars. Obviously, the risk of messing things up is a little bit higher. So, to help keep potential financial disaster at bay, the plants remove part of the human error factor and rely upon automated systems to keep things humming along smoothly. Systems much like the ones made by the company where Robert M. was a development manager.

The systems that Robert's group developed were not turnkey solutions; instead the software that they produced was intended to interact with the plant's hardware at a very low level. Because of this — and the fact that nobody wanted to be "that guy" who caused a plant to lose a crapton of money — all bug fixes and enhancements had to run though a plant simulator system first. While the arrangement worked well, Robert was always grateful when he was allowed to bring on additional help. And this is why he was very interested when heard that Vijay would be coming onto his team.

Considerable Generosity!

The company was run by the founder and his son. Phil, the son, was in charge of the "Advanced Technologies" group, which developed all sorts of neural networks and other things might be found on the latest cover of ComputerWorld; they sounded very impressive but never quite became products. All of them had advanced degrees in computer science and other, related fields. Perhaps not coincidently, all of the money-making products were developed and maintained by people without advanced degrees.

"I'm telling you Robert, you're going to really appreciate having Vijay around," said Phil, "He interviewed real strong and, get this. He has a PhD in Computer Science! You'll be thanking me by the end of next week, you'll see!"

Vijay's tenure, however, was temporary in nature. Until a project was available to truly engage Vijay's vast knowledge, he would be "on loan" to Robert's team to "improve his group's knowledge base" while gaining valuable real-world experience. "You'll want to exercise some care and feeding with that boy," warned Phil, "he likes to be right. But I have faith that you'll be able to handle him when he arrives first thing tomorrow!"

Welcome Aboard

When Vijay arrived on the scene, there was no mistaking him. His sunglasses and clothing made him seem like he jumped out of the latest J.Crew catalog, but his swagger and facial hair made him look more like Dog the Bounty Hunter.

Robert greeted Vijay warmly and started showing him around the office, introducing him to the receptionist, the other developers on his team, how to join the coffee club and other good information like that. Once acquainted with the development environment, Vijay's first assignment was to fix a minor bug. It was the sort of problem that you give to the new guy so that he can start to learn the code base. And later that afternoon, Vijay came to Robert's desk to announce that he had fixed the bug.

"Glad to hear that you tracked down the bug," Phil responded enthusiastically. "Did you run into any problems running the fixed code through the simulator?"

"I didn't need to!" replied Vijay, "it's a proven fix. It's perfect!"

Robert looked to a nearby colleague wondering if perhaps he had missed something Vijay had said.

"Vijay, it's not that I doubt your skills, but what exactly do you mean by a 'proven fix'?"

 

Bullet Proofing the Proof

Vijay left Robert's office and returned with a notebook. He explained that, basically, the idea is that you create a mathematical proof via a formal method that describes a system. What he had done was created a proof of how the system functioned, and then he recalculated after writing the actual fix.

While patting his notebook, he smiled and concluded, "therefore, this is my proof that the code will work — in writing!"

"Vijay,you work is quite impressive," Robert began, "but would you mind if we went over to the simulator and tried it out?"

Vijay was agreeable to the proposition and joined and Robert at the simulator. As per their normal test plan, Robert installed the patch and set up the conditions for the bug. Vijay watched on silently with a very stoic of course it will you idiot during the whole process. And then his mood suddenly changed when Robert found that the bug was still there.

"You see - the annealing temperature that appears on the operator's screen still reads -255F. Perhaps—", Robert began before being abruptly cut off.

"But I proved that it was correct!" exclaimed Vijay while stabbing his notebook with his pointer finger, "Now you see here! Page 3! There! SEE?!?!"

Quietly, Robert offered, "Maybe there is an error in your proof," but it did no good. Muttering under his breath, Vijay stormed back to his desk and spent the remainder of the day (literally) pounding on his keyboard.

The next morning, the founder's son, Phil, stopped by Robert's office. "Bad news Robert," he opened, "as of this morning, Vijay will no longer be working with your group. He was pretty upset that your software was defective and that it didn't work when he fixed it... even when his fix was proven to be correct."

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