Skip to content

Instantly share code, notes, and snippets.

@Darkflib
Created September 4, 2024 13:37
Show Gist options
  • Save Darkflib/d336f0a13e2a8a2f5880065dd833765e to your computer and use it in GitHub Desktop.
Save Darkflib/d336f0a13e2a8a2f5880065dd833765e to your computer and use it in GitHub Desktop.
Excerpt from 'the deadline'

What Kenoros proposed to teach the eighteen teams was a technique he called Last Minute Implementation, and it scared the hell out of Tompkins. The scheme involved deferring coding as long as possible, spending the middle forty percent or more of the project doing an elaborate, exaggeratedly detailed low-level design, one that would have perfect one-to- one mappings to the eventual code. It was this time spent on design that was supposed to result in a much reduced need for debugging.

In a project that was destined to last a year, for example, no coding would be allowed until the last two months. No testing would be done until well after that. That meant that when testing did begin, virtually every test had to pass. There was almost no time allocated for debugging.

"How can we run a project with no time for debugging?" Tompkins asked incredulously.

"The amount of time spent on debugging is a function of the number of bugs," Kenoros replied, as though he were talking to an idiot.

"Yes, but no time spent on debugging implies that we need to have..."

"No bugs. You got it. You're all right; you catch on quick."

"No bugs!"

"That's what you just said."

"How can we have no bugs?!?"

"Look, think about a bug you have just found in a module. Where's the bug?"

"In the module."

"No. It's on the edge of the module. On the very edge. Oh, sure, there are some easy bugs in the middle, totally local to that one module, but those are the ones that get picked up easily in inspections. The real bugs, the ones that take up your time, are the ones that have something to do with the inter- face between that module and the rest of its world."

"Right. Everybody knows that. So what?"

"So, when you find that bug, during debugging, you are looking at the wrong thing."

"What am I looking at?" Tompkins asked in some exasperation.

"You are looking at the module, at its inside. You are looking into the code."

"What should I be looking at?"

"At the design. The design is where you have all the information about interfaces arrayed in front of you."

"But we try to get the defects out when we review the designs. We already do that. Then, an enormous amount of debugging work is required to pull out the defects that slip though anyway."

"Wrong."

"Wrong? Wrong that bugs slip through design review?"

"No, wrong that you really try to get them out during design."

"How can you possibly say that?"

"I know that because I know from these years I have been knocking about that almost nobody ever does a design that gets close enough to the actual code to allow sensible review."

"Well, of course we do design. Everybody does."

"Of course. But they don't do it at design time. At design time, the team puts together a document. There is a bit of hand-waving about 'philosophy' and maybe a file layout or two, and then a proforma review. What they're doing is what- ever it takes to get management off their backs so they can get on with the coding. Finally, the manager says okay. You can get on to the next part. The team rejoices and puts the so- called design on a shelf where it is never consulted again. It's pure shelf-ware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment