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
iiii. Eventually, when the number of
is became too long even for him, he added numbers:
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:
- 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.
- One cannot start working on code changes without understanding code and being able to run the code on their machine.
- 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
You must be logged in to post a comment.