Call me jaded, but every time I'm starting up on a new project as a maintenance developer, I expect the worst. It helps to soften the blow when the code I have to maintain is, in fact, "the worst." Plus it makes it all the better when I get to maintain good code.

In the early 90s, Tim was called on for help with a beautifully written TurboPascal system (and he assures me that such a thing exists). His company was tasked not with improving the already excellent system but, puzzlingly, replacing it altogether. It was there that he first met Hung.

Hung was a friendly Korean developer working at the company. He was experienced with the application that was being replaced, which was used to manage landfills. He was highly intelligent and eager to help out wherever he could. English wasn't his native language, though, so occasionally his coworkers would have a hard time understanding him.

Going in to the project, no one on Tim's team knew why a system that was working well was being replaced. After Tim and two other developers from his company were sent on-site for the work, though, Hung told them all about it. They found out that some guy named "Edward" had talked the company into a full rewrite. He was an outside consultant making a fortune hourly. Evidently, he'd talked them into a rewrite so that he could keep his billing rate up.

Edward suggested that the new platform be written in C, using a third party UI library (since this was before Windows), and a third party printer library. Development began and he spent two years writing code for the system, leaving right before Tim and his coworkers arrived to finish the work.

Two years is a long time, and with Edward's high hourly rate, he must've produced something amazing, right? Well, not really. His code was marginally more useful than Paula Bean's — but only marginally. When Tim's team arrived, they discovered that Edward's two years had been spent writing wrappers around subroutines in the third party libraries. There wasn't any code that actually connected anything. None of the code even ran; it was all libraries. Hell, a lot of the code wouldn't even compile. The code that did compile was untested, and the functions often just didn't work.

Upon receiving news that Edward's (incredibly expensive) code had been next to useless, the company was upset. To save face, they insisted that Tim and his team use Edward's code. And since Edward's code was broken, someone would be assigned to fixes and maintenance to the wrappers.

The company decided that they'd use someone internal to maintain the code, and since Hung was an expert on the wrapper code, he was given the task. By "expert," Hung explained, the company meant that he'd met Edward about a week before Edward jumped ship. Hung had officially become the incidental expert — despite knowing next to nothing about Edward's code, he knew more than anyone else there. Hung would have to fix any bugs discovered by Tim's team while they were writing the application.

Tim's team was having an awful time trying to get their code running, as they were held up by countless bugs that all fell on Hung's shoulders. Despite his strengths as a developer, Hung was overwhelmed by the frequency and severity of bugs being reported.

Everyone on the project was frustrated. Tim's team couldn't complete their work until Hung completed his, and Hung couldn't complete his work, period. Hung started cracking. As his level of frustration grew, his command of the English language faded. When Tim needed to blow off steam, he'd stand outside of Hung's office to reaffirm that no matter how bad you have it, someone else is worse off.

Tim recalls a monologue from Hung:


Eventually, Tim would start laughing, so (all in good fun) Hung would start throwing things from his desk at Tim and screaming in Korean.

Poor, poor Hung.

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