Hiro’s employer, an international consultancy firm, hosted a number of applications for “enterprise” customers. They provided everything from HR solutions to order management tools. Each local office was independent, but a central corporate office would issue decrees to be obeyed as divine law.

One such decree ordered them to upgrade customers to a new, internally developed order management package, ASAP. Corporate had put a lot of time and effort into the tool, and wanted a successful roll-out. Hiro’s office did what they were told, and to prove their loyalty to their corporate overlords, they started by bringing their largest customer, Initech, on line. Hiro’s management proudly reported a successful migration.

And it was, at least for the first few days. Then new orders started timing out. Then old orders timed out on lookup. Then the application crashed constantly. Angry managers from Initech called corporate. Angry C-level types called Hiro’s office. Hiro’s angry managers called Hiro. Finally, an angry Hiro called back to the corporate office, to try and get support.


“I’m having an issue with the new order management package.”

“What new package?” Sam said. Sam was a senior developer at the corporate office.

“The one which we got a memo for- deploy ASAP. That one,” Hiro said.

A long pause waited with Hiro, as Sam dug through recent emails, trying to find the memo. “Oh… that. You… you rolled that out already?”

“The memo said, ‘ASAP’,” Hiro repeated.

“Oh, that’s not good.”

The cheap plastic handset groaned in Hiro’s death grip. “What do you mean, ‘not good’?”

“Well, the application doesn’t work. We’re pulling it, and corporate isn’t going to support it at all.”

Hiro reported this to his bosses. The chain of anger got swung around the office a few times, before wrapping tightly around Hiro’s neck. His manager explained, “We can’t admit to our customer that we can’t fix our own software. We’re a consultancy! How would that look? We can’t roll-back, we can’t switch to a third-party tool. We have to fix this, which means you have to fix this. Make this work, Hiro.”

The first obstacle was getting access to the code. Corporate didn’t use source control. Simply copying source files around didn’t work- no one was clear on what dependencies the product had. Eventually, corporate sent a VM image of Sam’s PC, which was the environment Hiro had to develop in.

The code was “well documented”, in the way that all terrible code is well documented:

//gets customer by ID
public Customer getCustomerById(int id) { … }

Comments never approached being useful. The nearest they came was a terse description of the design pattern in use. bridge-flyweight hybrid pattern, abstract builder factory for the decorator were scattered through the code. The original architect- not poor Sam, who only touched the project in its final days- didn’t use design patterns to overcome common problems. Instead, he invented problems to justify trying every permutation of every design pattern- real or imagined.

The code was lambda crazy. Hiro found one peculiar function which returned a lambda that itself returned a lambda which also returned a lambda- down seven layers deep. LINQ statements were nested the same way. The simple act of creating a new order involved 4,000 unique database operations, each using its own connection object. 10,000 records were added or modified in the process. Common cases, like accepting two orders from the same customer, for the same product, in the same quantity, caused a crash.

Other “patterns” lurked in the code. For example, most of the numeric variables were declared long. Most of the methods expected int parameters. To resolve this, they used this pattern again and again:

public void someMethod(int param) { … }
long myVar = someNumber;

“There is no fixing this,” Hiro told his boss. “If we junk this, I can deliver the actual functionality our customer needs in two months.

“Corporate spent years on this! We can’t throw away all of that work. And we certainly can’t take two months! We need this application fixed now.”

In the end, it took six months to stabilize the existing code base. It might have gone faster, but Hiro’s boss kept throwing more people onto the project. Each time some arbitrary deadline that none of the developers agreed to passed, he dedicated another resource. No one was happy with the result, least of all Sam back at the corporate office- once the application was mostly working, Hiro’s boss won the argument. Corporate would own and support this beast from now on.

Jenga image By Jorge Barrios (Own work) [Public domain], via Wikimedia Commons
[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!