Paul admits that he should never have been hired. In fact, I think his exact words were, "I should have never been hired." But he was, and there wasn't a whole lot he could do about it. Given what he was up against, I doubt many of us would have had a different fate.

The first obstacle Paul came across was the Executive Vice President, also known as the soon-to-be Father-In-Law. Mr. Howell (as I'll call him) knew that Paul was a programmer. He also knew that his company employed programmers. He did the math and approached his soon-to-be Son-In-Law about working at his company.

Paul: I appreciate the offer, Mr. Howell. To be honest, I'm not sure that a large stock exchange is right opportunity for --
Mr. Howell: Awwww, come on. You'll like it!
Paul: Well, to be honest, I don't have any experience in the field and am not sure how well I --
Mr. Howell: Awwww, come on. You'll pick it up; it's easy!
Paul: Err, but, your company is a Java shop; I'm a C# programmer and have never used Jav--
Mr. Howell: Awwww, come on. You can use your "C#" if you'd like!

Paul hesitantly agreed to an interview. This is where he met the second obstacle, the Hiring Manager. The Hiring Manager was in the midst of a political war with a rival manager. He had some strong intelligence on his rival, and knew that he was planning to usurp projects from his division. Paul was the perfect opportunity for some defensive action: a "Permanent Resource Request Form" was strategically filed and Paul was given the thumbs-up from the Hiring Manager.

Paul's third obstacle was the Technical Lead. Desperate to fit in with his higher-ups, the Technical Lead overlooked the whole "lack of financial experience" and the "C# thing" and tacked his gold star on Paul's résumé, right next to the Executive Vice President's and the Hiring Manager's.

And then came the fourth obstacle, the Job Offer. This proved to be Paul's downfall. It was just too good of an offer. We're talking not just bling, but bling-bling. A 60% raise. How could anyone pass that up?

Fast forward seven months into the job and Paul had just finished his portion of The Massive Upgrade Project. His component was a simple, .Net-based messaging system that interfaced with the rest of the Java-based system via web services. Since none of the Java engineers trusted Paul's .Net code, it was given extra-careful functional and load testing. It passed with flying colors.

A month or so later, The Massive Upgrade Project went live. Or more accurately, it killed everything. No, really. Its failure made international news and caused trading to be halted for an entire day (this is a huge deal for stock exchanges). After the company managed to rollback the system, everyone's top priority shifted to blaming and avoiding being blamed. With his .Net system, Paul became the target of massive finger-pointing.

In the Preliminary Failure Report, a Senior Java Programmer laid the blame on an exception being thrown by Paul's system. It looked something like this: 

java.lang.NullPointerException
    at java.io.Stream.ctor()
    at java.net.HttpRequest.GetResponseStream()
    at com.exchange.java.application.MailManager.getResponse()
    at com.exchange.java.application.MailManager.sendMail(string recipi ...
    at com.exchange.java.application.ActionHandler.failure(string message)
    ...

Paul tried to explain to the Senior Java Programmer that this couldn't possibly be an exception from his system. His system was entirely .Net, and .Net exceptions do not look like that. They also are not littered with "java.lang." The Senior Java Programmer didn't by it; it was escalated to the Lead Java Engineer.

Paul tried to explain this again the Lead Java Engineer, saying that his portion isn't Java-based and doesn't throw Java exceptions. The Lead Java Engineer didn't buy it; it was escalated to the Line Manager.

The explain-disbelief-escalate process worked its way through the Line Manager, the Director of Development, and, finally, to the CTO. It might have made it further, but by that point, the other Java programmers identified the Real Problem: a poor architecture resulting in massive failure as a result of concurrent usage. Whoops.

Only a single QA engineer was let go as a result of The Massive Failure. Paul actually stuck around for another year and finally put in his notice a few weeks before the rollout date for The Massive Upgrade Project 2.0. He hasn't looked back since.

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