George G. came to the Pierce & Pierce office in good spirits and with high hopes. After finally gathering the courage to run away from his previous job, which had involved maintaining a million-line, 15-year-old mess of a codebase, he'd spent the last month interviewing with nearly every tech company in his area. Here he'd found his Promised Land: a modern-looking, professional company with a suite of cutting-edge technologies and, most importantly, a new and interesting project to which George would be assigned.

Timbuktu Excavation 1

Or at least that was what Pierce & Pierce had promised at the interview.

"Well, you see, there's been a reorg." George had barely sat down at his desk for the first time when his manager brought him the news. "All new projects are on ice. We're gonna be putting you on our flagship product instead. Don't worry, we'll have something real cutting-edge for you soon!"

Flagship product? That could only mean one thing: legacy code. Another aging codebase which, thanks to the company's "innovative performance-boosting management methods," clocked in at five million lines of uncommented, undocumented code. As much as George wanted to get up and leave at such news, he decided to bite the bullet and give Pierce & Pierce a chance ... for now.

He received his first assignment almost immediately. The application failed to read a particular line from a config file, and the task was to investigate and fix the issue.

Well, that should be simple, he thought. I just need to find the place where the config file gets opened, then there should be some loop that reads it and looks for that line. Easy-peasy.

He submitted a one-hour time estimate, giving himself some leeway, then got down to hunting the bug.

Unfortunately, things weren't so simple. What was supposed to be a quick, introductory trip through the codebase turned out to be a strenuous excavation through layer upon layer of abstract factory builders, inline lambdas spinning off separate threads, callbacks to callbacks, and other examples of architecture astronautics—all to simply read the configuration file.

Four days later, George managed to find something resembling an error logger. He set a breakpoint and ran the application, hoping to work his way through the call stack to where the issue lay.

Sure enough, the breakpoint was hit almost immediately. But even before George started reading the stack trace, he knew it wouldn’t be of much use. The list of classes looked something like this:

ErrorReporter
ErrorInterface
ErrorJuggler
ErrorMux
ErrorRecorder
ErrorCatcher
ErrorFinagler
ExceptionModerator
ExceptionFilter
ExceptionAdvertiser
ExceptFondler
ExceptIncoming
ExceptPeeker
ErrorPoster
ErrorLayout
ErrorGenerator  
ParseDistributor
ParseThis
ParseThat

//snip 19 lines

ReadInitFile

Well, at least I know where the log is, he thought. Maybe there's something interesting in there?

[2015-08-05 12:12:33] Parse error.
[2015-08-05 12:08:45] Parse error.
[2015-08-05 11:59:27] Parse error.
...

Not a chance. Apparently, somewhere deep in the error handling code, someone got lazy and dropped all the potentially useful error information.

That was the last straw. George was already mentally drafting his resignation letter, but to his shock, his manager beat him to it the very next week.

"We're going to have to let you go," he said. "We like you, but you're just not getting enough done."

And so, after one week with zero bugs squashed, George returned to job-hunting. The wasted time annoyed him, but he was blessedly free from supporting that gigantic codebase.

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