Most terrifying professional artifact

Gather around the fire, kids; I am about to tell you a horrifying story.

“The most terrifying professional artifact Neal ever encountered was a single C function that served as the heart of a commercial software package whose CC was over 800! It was a single function with over 4,000 lines of code, including the liberal use of GOTO statements (to escape impossibly deeply nested loops).”

— Fundamentals of Software Architecture: An Engineering Approach by Mark Richards, Neal Ford

In the summer of 2002, I worked on one of the early implementations of online banking. I had a coworker who mostly kept to himself. He was responsible for a significant part of the project. While the rest of the team worked together and might have created the impression of inefficiency, this particular developer was a lone wolf who worked seemingly long hours and always delivered. The management loved him. On the surface, he made all of us look bad.

Except when he resigned, and I inherited his code.

His entire work was confined to a single 40000+ long JSP file — Java code commingled with HTML, with a giant if/else statement covering all possible execution paths, using HTTP redirects to MacGyver a GOTO.

While a standard software practice is to give meaningful names to variables, he would name them i, ii, iii, iiii. Eventually, when the number of is became too long even for him, he added numbers: iiiiiii1, iiiiiii2, etc. 

I was given assignments to fix bugs in his code, and the only way I could work on that code was by convincing my boss to let me refactor it first. It was no simple task because I lacked the gravitas to convince otherwise non-technical management that certain things needed to be done at only two years out of college.

Ask yourself: at two years out of college, have you faced a situation like this?

I was given a few days to figure it out. The only way I could wrap my head around this code was by printing it out, taping printed sheets together, spreading it on the floor, and crawling over it using a highlighter to annotate blocks of code. Having spent about a week working from 9am to 11pm, I managed to refactor that monstrosity.

I learned some valuable lessons from this experience:

1. Developers are like toddlers. When a toddler is quiet, it can only mean one of two things — either he’s napping, or there is trouble brewing.
2. One cannot start working on code changes without understanding code and being able to run the code on their machine.
3. Sometimes, to understand the code, one must resort to old-fashioned paper and pencil tactics to untangle the mess.

---

Featured image: Garnished Spaghetti in Ghana via WikiMedia Commons