Margin Scribbling

Informal name for an AntiPattern that I'm sure exists somewhere else under a different name.

This is a phenomenon I've run into several times over the years, and somehow I still get sucker-punched by some new variation.

Customer says, "Thanks for coming. We've decided to automate this [foo] activity because it's just getting too hard to do manually (or with Excel, or a simple text/doc file ...) and this here is a sample of the report. All I want is a Program That Does This (tm)."

Questions are asked. Column headings are reviewed. Workflow is delineated. Sample transactions are walked through the existing system. The math is formalized. Everyone agrees that This Is What We Want (tm).

Work begins. Schema is drawn up. Code fragments are defined. Menus are added. Boards are hammered and concrete is poured. Plumbing and electrical are installed. A prototype is born.

"So, here is the entry screen for your current Sheet Six, and we've arranged it so entry proceeds very like the paper system you're now using."
"Where do the Special Notes (tm) go?"
"What's a Special Note?"

At this point a spreadsheet is presented. In the margins and/or on the column boundaries are little red scribbles.

"Here's a Special Note that says we're treating his account as paid but we haven't actually received his check yet."

Now it turns out that everybody in the shop knows about these margin scribbles. They are Special Cases (tm). They are a set of weirdly formalized irregular practices. They are not handled anywhere in the code or schema. I'm about to do a bunch of free work.

My first run-in with MarginScribbling was more than 20 years ago, with an insurance agency that had odd payment management practices. My latest encounter was this year, with an in-home care outfit having odd employee scheduling practices.

So, does this AntiPattern have a formal name?

-- GarryHamilton

Question: is it something that could be generally solved by providing your own margin to scribble in, so to speak?

We did that, but we had to invent a set of rules for the previously ad-hoc scribbles, as they actually changed where money showed up on reports and how math was done in certain places.

This isn't an AntiPattern, it's a pattern. An AntiPattern might be ignoring this pattern (also known as a gloss) while gathering requirements. What seems "weird" or "irregular" to a programmer is often vital to a business. -- EricHodges

Agreed. In the case of the insurance agency, it was in fact irregular. We had to print two sets of reports, one that was sent to the insurance company of record and one that was only seen locally. The insurance companies involved would have frowned sternly on their practice of covering payments for special customers while waiting for the actual money to arrive.

So what's the pattern name for this kind of thing? -- gh

I don't know any business practice pattern names. We could call it "exceptions". -- EH

Back when I was doing custom application development for small and medium-sized businesses, I found MarginScribbling to be almost a rule rather than an exception. The justification was frequently something along the lines of, "What? We can't afford to re-print all these old forms! We've got boxes and boxes! So now we write the serial number in the corner, right here..."

To address this, my company and I developed an analysis methodology based on a variant of data-flow diagrams and a set of pre-defined questions. The diagrams were intended specifically to capture and model the paper flow, and the analyst was expected to collect copies or samples of every relevant filled-out form, spreadsheet, existing data-entry screen, or ad-hoc Post-It(TM) note and cross reference these to the diagrams. The pre-defined questions were designed to put the analyst in the role of a naive employee learning the ropes, rather than that of an "expert," in front of whom some users would otherwise feel foolish admitting their procedural hacks. If circumstances permitted, we encouraged the analyst to temporarily take on employee roles for (hopefully) long enough to catch the nuances of procedure that might otherwise be missed. We found this notably reduced the number of "surprises" compared to before we adopted the methodology. -- DaveVoorhis

Sounds like the opposite of OnsiteCustomer, an interesting duality.