spaghetti-code-killer

The Architecture

Chapter 6 of 14

The variable names are the first thing I notice, once I know whose they are.

The original developers wrote code the way programmers who expect to be long gone write code: abbreviated, terse, self-referential only to the immediate problem. `ptDoseMlt`. `adminAmt`. `sysHdlr`. Variable names that save time typing and cost it three times over in reading. I've been working around these sections for six days without really reading them — furniture in a room I spend too much time in. They've been background.

Marcus named things like he expected someone to understand them. `patient_dose_multiplier`. `safety_threshold_maximum`. `last_name_initial`. Not abbreviated. Not shortcutted. The function that manages how the system calculates scheduled medication delivery is called `calculate_scheduled_dispense_window`, which takes four times longer to type and communicates exactly what it does to anyone who didn't write it and has to understand it later. He cared about the later.

I've been sitting with this codebase for three days since I put a name to the style. Before that, I ran the attribution analysis on architecture patterns and commit rhythms and commenting frequency — building a profile from the code's behavior — method, execution, the signature that marks the work as one specific person's. I knew I was looking for a specific kind of mind before I knew whose mind it was. Now I'm re-reading functions I've already documented and I can see him in every line.

The function called `calculate_scheduled_dispense_window` is an argument I've heard before. Four sub-functions nested inside it, each one handling exactly one piece of the calculation, the output of each feeding the input of the next. The architecture is a conviction: break the problem into the smallest possible pieces and solve each one like it's the only thing that matters. If you've solved each piece correctly, the assembly handles itself. This was not a casual approach for him. This was how he thought about everything — not just code, not just problems with technical solutions. The way you break down a question so that each component becomes answerable, and the answer to the whole emerges from the pieces without requiring a leap.

I put my red pen to the margin. Mark the function header with an asterisk and a note: MC architecture — deep function tree, single-responsibility, see also dosage_override. I keep reading, and find the edge-case comment at line 847.

// patient_dose_multiplier should NEVER be passed downstream unchecked. // I got burned by this in the Hartfield build -- null propagated through // four functions before anything noticed. The check here is load-bearing. // Don't remove it because you think the upstream handles it. The upstream // doesn't. Trust this.

He wrote it in the second person. Not the upstream doesn't handle it but the upstream doesn't. A reader addressed. A specific reader who might reach this line, confident in the upstream, about to make the mistake he made. The kitchen comes back before I can stop it.

Both laptops open. The coffee I made, neither of us touching it, the mug going cold in the space between us on the table. His hands moving above the keyboard, drawing the shape of something in the air because he couldn't explain a concept without mapping it physically first, his fingers tracing dependency trees as if they were tangible. The Hartfield build — I don't remember the name now but I remember the shape of the story: a null propagation that ran through production for six weeks, undetected, because the architecture he trusted was only as good as the assumptions he'd built it on, and one assumption was wrong. He was embarrassed. Not the kind of embarrassed that wants comfort — the kind that has already metabolized the failure into knowledge and is slightly impatient with itself for having needed the lesson.

He wrote Trust this in a comment for future developers. Past tense: got burned. Present tense, lowercase, addressed to whoever came next: Trust this. The coffee in front of me is cold. I've been here since six-thirty and the hours have gone past unregistered.

I mark line 847: EVIDENCE — style match, experiential reference, second person address. Technical. Specific. The note I'd write about any evidence. I write it in the same capitals I use for every margin annotation, not because it changes what I feel about the kitchen table or the cold coffee or his hands moving above the keyboard, but because naming things correctly is the one control I have over the fact that I'm reading his mind through his code and the code goes seven murders deep.

When I close the printout and drive out to MediCore, Derek Huang is in the conference room — same frosted glass walls, same afternoon light cutting across the table at the angle that makes everyone look tired, the energy drink in front of him warm and forgotten. He looks like the past several days have landed hard, the weight of someone who has been waiting for the worst to happen and has finally run out of the energy it takes to keep waiting.

Ray sits across from him at the angle we've developed over two years of partnership without ever explicitly negotiating it: close enough to be a presence, far enough that Derek's attention stays on me. I slide the cooperation agreement across the table. Derek picks it up without touching the energy drink. He reads it slowly, actually reading rather than performing it. The pen cap clicks against the edge of the table — the tell I clocked on day four, the specific nervous rhythm of hands that need something to do while the rest of the body holds still. He reads it a second time, then sets it down. The pen cap stops.

"What do you need," he says. Not a question. His voice has dropped out of the register he's been using for six days — the defensive, jargon-forward register of someone managing liability in real time — into something that sounds like a person talking to another person.

"Everything you know about the parts of the codebase you didn't understand," I say.

He looks at me across the table. The afternoon light does the thing it does in institutional conference rooms, flattening everything, making expression hard to read. He keeps looking.

"That's most of it," he says.

"I know. That's why I'm asking."

He picks up the cooperation agreement and slides it back toward me. His pen is in his hand and he signs it without recapping it, the cap sitting at the table edge where it landed when he stopped clicking it. He dates it. He slides it to Ray, who countersigns as witness.

There's a silence that isn't uncomfortable. Something has shifted in the room — the thing that shifts when two people stop performing at each other and start actually sitting in the same space. Derek looks at the signed agreement for a moment. "You want to start now?" he says.

We spend most of day eleven in the lab. Ray sets up the spare workstation and Derek works through the version history layer by layer while I work through the architecture, and every ninety minutes or so we compare what we've found. He brings his energy drinks. I have the coffee machine. The overhead fluorescent runs its constant low interference.

I've printed three versions of the main module — the git diff across three significant commit periods — and laid them across my desk in order. Derek labels them without being asked: Before Marcus. Marcus. Me. I look at the third label.

"Why not a date range?" I ask.

He considers it. "Because that's what it is," he says. "It's what I did to the codebase. Seemed more accurate." He says it like a forensic observation, nothing in it that wants anything from me. I note the shift.

The Before Marcus sections are visible in the outer callbacks — the scheduling functions, the patient database interface, the first four layers of the dosage logic. Flat functions doing multiple things. Terse variable names. Comments that document the what with no interest in the why. It's the work of programmers who shipped a product and expected someone else to maintain it forever, which turned out to be correct. They got their wish.

Marcus starts at layer five. You can feel the transition the way you can feel a neighborhood's character shift walking through it — the architecture opens up, the functions compress to single responsibilities, the names become generous and specific. His code addresses a reader. The original developers wrote for the compiler and hoped a human could follow; Marcus wrote as if a human following was the whole point of writing it.

Derek's sections are a third thing: overlaid on both without understanding either. He maintained the surface, filled the gaps, never debugging the deep architecture because he couldn't trust what he'd find there. Two years of patches competent in isolation and coherent only as anxiety made structural. He added validation without knowing what he was validating. He wrapped functions in error handling without knowing what the errors meant.

"I kept a list," he says mid-afternoon, not looking up from the version history on his screen. "Functions I flagged as 'don't touch without understanding first.' I thought I was being responsible." He's quiet for a moment. "There were eleven of them. All Marcus's."

I look at my printout, where I've marked Marcus's clean sections in red. Eleven asterisks. Different functions than Derek's list, overlapping ones — same logic either way: this code is load-bearing and its weight isn't obvious from the surface.

"The kill mechanism is in layer twelve," I say. "Inside one of the functions you flagged."

"I know," he says. He doesn't say it like it surprises him anymore.

What his expression holds is harder to name. Awe and fury are both in it — the particular combination of someone confronting evidence that the person who made their professional life a misery also built something genuinely beautiful, and that the beauty is inseparable from the harm. Derek inherited the elegant function that kills people. He maintained it without knowing what it was. The code that was best in the codebase was the most dangerous thing in it, and he kept it intact out of appropriate professional caution.

I put a fresh asterisk next to the callback layer eight section header. I've been passing through this section to get to the deeper layers — marking it as Marcus-authored and clean and not the thing I was looking for. The kill mechanism lives at layer twelve. Layer eight is clean. Layer eight is just where the descent begins. Tomorrow, we go in.

Day twelve, and it's ten PM — the quiet that settles in here after seven is its own kind of sound, the server hum filling the space where voices were, the coffee machine's element clicking off for the last time, the stillness of a room designed for work after the work has nominally stopped. Ray left at six, two hours past when he wanted to and three hours before he'd have left me alone with any comfort, but Thursdays are his kids' school thing and I told him I was wrapping up, which I wasn't. Derek went back to MediCore to deal with whatever Victor Russo is currently trying to make him sign. I have the lab, the printouts, the quiet.

I've printed the layer eight module. Forty-two lines. I looked at this section six days ago — I marked it as a Marcus-authored block, noted the architecture, checked the conditional logic for anomalies. Clean. The safety parameters here are intact. Nothing at layer eight contributes to the kill mechanism at layer twelve. I documented it as such and kept moving toward the deeper layers. Reviewing my earlier annotations now, I notice what I missed.

The anomaly isn't in the logic. It's in the comments. I've been reading Marcus's work comments as forensic artifacts: evidence of authorship, traces of presence, the thing that connects the account name to the body of the code. What I'm looking at now doesn't read like a work comment. It's not an edge case flagged, not a warning for future maintainers, not the confident second-person address of someone who got burned and wants you not to be. The comment block above `calculate_scheduled_dispense_window` is twenty-three lines long. I catalogued it on day six as extensive commenting, style match and moved past it — I didn't read it.

I pull the printout flat against the desk and lean close to the screen to pull up the original — unformatted, unscrolled, the indentation exactly as Marcus committed it three years ago. The fluorescent overhead. The mug at my elbow.

The commit timestamp on this block is October, three years ago. Before the deaths. Before any of this. Before I knew this codebase existed, before I knew he'd been inside it, before the seven names in alphabetical order on my corkboard had been anything other than the living occupants of rooms at a nursing facility I'd never heard of. I read the first line of the comment block.

My hands stop on the keyboard.

It isn't documentation. It isn't a warning to a future developer or a note about an edge case or a reference to something that went wrong in a previous build. It is addressed — not to a general reader, not to whoever might come next, not to the compiler or the codebase or the engineering team. The second-person singular in the first line is not the universal you of technical writing.

I know who he was talking to.

← PreviousContentsNext →