The Bill Berger Special

Shadow IT gets a bad name. This is the story of Chorus.

Mock Mock
Muffit II. Robot daggit. Macro1 operator. Rest in peace.
(See the real Muffit II — yes, it was a chimp in a suit.)

I'm walking down the hall in the Initiative suite at 5700 Wilshire, the building where I spend most of my "in-office" career. It's around 2008, in the early days of advertising on the internet, and these people had zero support for their work from anything a typical ad agency would provide. Donovan Data Systems, who rarely think ahead, had decided that digital media was just another form of "print." So, yeah, you could put in all your placements as print insertions which, in fact, did nothing to help you. Instead, most digital teams of this era started to create what I like to call Excel Mongo Linko Crazo.

Excel Mongo Linko Crazo is the scariest of all software patterns. There are two key features that the folks at Excel built to enable these things: VLOOKUP instead of tables, and "external references" — the horror of horrors — which is both a join and a projection depending on the circumstances.

What is an external reference?

An Excel formula like ='[OtherFile.xlsx]Sheet1'!$A$1 that reaches into a different workbook and pulls a value back. If that workbook is on a shared drive, another person's desktop, or a laptop that went home for the weekend, the formula breaks. Chain a dozen of these across multiple files and you've built a distributed database with no server, no schema, no backup, and no prayer.

If you've never seen an external reference in Excel, count your blessings. People built careers on these things. Entire media plans lived inside a web of linked workbooks that would collapse if someone renamed a folder.

This was the state of the art in digital media operations in 2008. Not because people were stupid — they weren't. They were solving real problems with the only tools anyone would give them. IT wasn't coming. Engineering didn't know they existed. So they built what they could, and what they could build was Excel.

.xlsx .xlsx .xlsx .xlsx .xlsx VLOOKUP ← VLOOKUP ← VLOOKUP ← ????
Excel Mongo Linko Crazo. Each dashed line is a prayer.

I find my way to an office where three people are stuffed in and meet Muffit II, the robot dog from Battlestar Galactica.

MUFFIT II"Mock Mock. Mock Mock."
English:"Kill me. Kill me."
BILLIt'll be OK, Muffit.
MUFFIT II"Mock Mock. Mock Mock."
English:"I'm leaving here. Take over my work, please."
BILLSorry to see you go, Muffy. Can you show me your work?
MUFFIT II"Mock Mock. Mock Mock."
English:"I have built automation for the key reports for our key automotive client. I called it Macro1."
BILLOK. Can you take me through it?
MUFFIT II"Mock Mock. Mock Mock."
English:"Open these seven spreadsheets. Place the selection in each seven carefully on the first page on the green highlighted cell on Sheet1!A1."
BILLSure, but...
MUFFIT II"Mock Mock. Mock Mock."
English:"Now we are ready to execute. I run Macro1 now."

At this point, Excel starts having convulsions. Workbooks selected. Worksheet selected. Range selected. Copy executed. New workbook created. Cell contents out of the copy buffer land. The lights in the room start to dim as the machine's effort is respected by all in the room.

What is a recorded macro?

Excel has a "Record Macro" button. Press it, do some work — click cells, copy, paste, format — then stop recording. Excel saves every action as VBA code. The result is something like:

Sub Macro1()
    Range("A1").Select        ' which A1? on which sheet? in which workbook?
    Selection.Copy            ' copies whatever is "selected" — stateful, fragile
    Sheets("Sheet2").Select   ' hardcoded sheet name — rename it and this dies
    Range("B5").Select        ' another hardcoded address
    ActiveSheet.Paste         ' "active" sheet — depends on what you clicked last
End Sub

Every single step is a hardcoded cell address. No variables, no loops, no logic. It's a replay of your exact keystrokes — and it only works if the world looks exactly the same as when you recorded it. Move a column? It breaks. Rename a sheet? It breaks. Open the workbooks in a different order? It breaks.

Human-written code does the same job without any of that fragility:

Private Sub MoveValues(ByVal sourceSheet As String, _
                       ByVal sourceRange As String, _
                       ByVal destSheet As String, _
                       ByVal destRange As String)

    Dim src As Range, dst As Range
    Set src = Sheets(sourceSheet).Range(sourceRange)
    Set dst = Sheets(destSheet).Range(destRange)

    If src.Rows.Count <> dst.Rows.Count Or _
       src.Columns.Count <> dst.Columns.Count Then
        Err.Raise vbObjectError + 1, "MoveValues", _
            "Range size mismatch: source is " & _
            src.Rows.Count & "x" & src.Columns.Count & _
            " but destination is " & _
            dst.Rows.Count & "x" & dst.Columns.Count
    End If

    dst.Value = src.Value

End Sub

Four parameters. A guard clause. One line of real work. Look at what's different:

Call it with MoveValues "Sheet1", "A1:D50", "Sheet2", "B5:E54" — or any other combination. Rename the sheets? Change the parameter. Add ten more moves? Call it ten more times. The procedure doesn't care what's selected, what's active, or what order you opened things in.

A recorded macro is a photograph of a process. Written code is a description of one.

There's a particular kind of silence that falls over a room when someone runs a macro like this. It's not awe. It's not respect. It's the silence of three people watching a machine do something they don't understand and can't stop. The cursor moves on its own. Cells highlight in patterns that follow no visible logic. Somewhere deep in the VBA editor, Macro1 is executing its 4,000 lines of recorded steps — every one of them a hardcoded cell reference, a specific worksheet name, a path that exists on exactly one computer in the world.

Nobody breathes. The screen flickers. A workbook opens, disgorges its contents into a waiting cell range, and closes. Another opens. The clipboard is working harder than anyone in the building.

And then — it stops. A final workbook appears, populated with numbers. The report is done.

Muffit looks at Bill. Bill looks at the screen. The three other people in the room look at each other.

MUFFIT II"Mock Mock. Mock Mock. Mock Mock."
English:"Report done. Very efficient. Now yours."
BILLHm. Muffit, I don't think I'm ready to take this over. Can I ask you a question? What is a variable? You know, in VBA — why would you use a variable?
MUFFIT II"Mock Mock. Mock Mock. Mock Mock."
English:"What is 'variable'? Sounds like over-engineering. This works well."
BILLDo me a favor and try to put a variable somewhere in your code, just to see what it's like?
MUFFIT II"Mock Mock. Mock Mock."
English:"Not software engineering. Just here to make reports."

So I thank Muffit and ask that he forward his work to me. This was difficult, as the external links referenced things that I needed to get access to, but I finally managed to open it. I looked briefly at Macro1 and saw one of the first lines: Selection.Copy(). I closed the workbook and never opened it again. Instead, I met someone else on the team named Ben Saneboy.

He too had the look of someone who wanted an Excel Mongo Linko Crazo. He recognized the difficulty of maintaining Muffit's solution, but he had a better Excel Mongo Linko Crazo pattern of his own that "works well."

What is shadow IT?

Software built by business users — not IT, not engineering — to solve a problem nobody else will solve. Usually in Excel, Access, or whatever's available. The term is almost always pejorative. But the reason shadow IT exists is that official IT doesn't show up. People build what they need because the alternative is doing nothing.

The problem isn't that shadow IT exists. The problem is that most of it is built without engineering discipline — no version control, no separation of concerns, no plan for what happens when the builder leaves. That's the gap this story is about.

This is the thing about shadow IT. It's never just one person. It's a culture. Muffit leaves, and the vacuum doesn't get filled by engineering or IT or a proper system. It gets filled by the next person with enough initiative and enough Excel to be dangerous. The pattern reproduces. Each generation of shadow IT builder looks at the last one's work and thinks: I can do this better. And they can — slightly. But "better" in the Excel Mongo Linko Crazo world means a cleaner spreadsheet with the same fundamental problem: one person's brain is the documentation, one person's laptop is the server, and one person's departure is the disaster recovery plan.

Ben Saneboy was smarter than Muffit. He could see the mess. He understood why Macro1 failed. But his solution was still built on the same foundation — Excel as a platform, cleverness as architecture, and "it works on my machine" as the acceptance criteria.

Ben actually listens when I tell him there's a better way. Let's use a database for this work. I know that sounds obvious, but it was a huge leap of faith for Ben. He was very comfortable with Excel and had zero experience with any sort of relational database. I tell him: "Trust me. I'll make this work." He does, and over a matter of weeks we talk about their work and needs. Not a solution yet — just understanding what's going on here.

As a reward for his faith in me, I create a full transactional and reporting system using Microsoft Access. Yes, Microsoft Access, the greatest evil inflicted on the world, and a very nice platform to build simple department-level tools depending on who you talk to.

Microsoft Access: evil or misunderstood?

Both. Access has a real relational database engine, a forms designer, a report builder, and VBA for glue. It's also got 2GB size limits, multi-user locking that fails under pressure, and a query designer that teaches you just enough SQL to be catastrophically wrong about joins.

But for a department-level tool with a handful of users and a clear scope? It's a rapid prototyping environment. Build it in weeks, not months. Replace seven linked spreadsheets with one normalized schema. The key is knowing what Access is — a tool — and not pretending it's enterprise software.

The difference between a Bill Berger Special and a Macro1 is right here. Muffit recorded his keystrokes and called it automation. I sat down, listened to what the team actually needed, designed a schema, built forms for data entry, wrote queries for reporting, and delivered something with structure. Tables with relationships. Forms with validation. Reports that pull from one source of truth instead of seven workbooks on a shared drive.

The system ends up with the following features, in a well-designed schema with cleanly separated code from presentation:

  1. Full transactional schema including data lifecycles like "planned," "revised," "reconciled," and a new concept called "best," which coalesced these values to their most accurate value.
  2. Full audit log where each change to any field was recorded as to the prior and new value. Included the user who made the change and a reversion capability.
  3. Full backup system that backed up the primary database each morning. The first user to open the front end would initiate a simple copy of the backend to avoid corruption typical in Access databases.
  4. Integration with both Donovan Data Systems and DoubleClick. Data could be moved in and out of the system without rekeying.
  5. Split database design with front end and back end separated, so updates to the front end require no migration on the back end. Version controls exist and the front end will not run if it isn't the most current version. Pull down a new FE file from the network share and keep working.

The team is overjoyed with their new tool. They want to give it a name. Ben Saneboy suggests "Godhead" or "StupendousMasteryOfEverything." At the time, we were trying to get the team to move to a new tool called "Symphony." I suggested "Chorus," and the name stuck.

Read that list again. That's not shadow IT. That's software engineering.

Data lifecycles — planned, revised, reconciled — with a "best" value that coalesces to the most accurate number available. That's a state machine. A full audit log with field-level change tracking, user attribution, and reversion. That's compliance infrastructure. A backup system triggered by the first user of the day. That's operations. Integration with both the billing system and the ad server, eliminating the rekeying that consumed hours of human time every week. That's ETL. A split front-end/back-end with version control that refuses to run stale code. That's deployment discipline.

This is the gap. Not between shadow IT and "real" IT — between someone who builds things that work and someone who builds things that last. Every feature on that list exists because I asked a question that Muffit never thought to ask: what happens next?

What happens when the number changes?Audit log. What happens when someone makes a mistake?Reversion. What happens when the database corrupts?Morning backup. What happens when I update the forms?Split design + version check. What happens when the person who built it leaves?It keeps running.

That last one is the whole point. Muffit's Macro1 died three runs after he left. Chorus was still running years later. Not because it was built on better technology — Access is Access — but because it was built with intent. Every design decision answered a "what happens when" question. That's not a CS degree. That's giving a damn.

And the name? Ben wanted "Godhead." I suggested "Chorus" — because we were trying to get the team onto a platform called Symphony, and a chorus supports the symphony. It doesn't compete with it. It harmonizes. It fills the gap between what the enterprise provides and what the team actually needs.

That's the Bill Berger Special in one word. Not a replacement for the system. Not a rebellion against it. A chorus — the part that makes the whole thing work, built by someone who was never supposed to be building software at all.

Shadow IT is an issue for sure, but the lack of tooling for business users is enormous. Many systems expect people to work like robots. Enter data into form, robot. Keep clicking and mousing all day, robot. My solutions were always based on a gap in the "professional system," but those systems always assumed the worst about people. I'm not going to spend time reading a ream of paper reports, but that's what most systems would deliver. Not intelligence — mainly distributed CRUD. Distributed CRUD is essential, but the job shouldn't stop there.

What is CRUD?

Create, Read, Update, Delete — the four basic operations of any data system. Most enterprise software is just CRUD with a nice skin. That's fine for storing and retrieving data, but it doesn't think. It doesn't tell you what's important, what changed, or what you should do next. The gap between CRUD and intelligence is where the Bill Berger Special lives.

When I build, I use good, repeatable patterns that last the test of time. My software would run for years without replacement, because end users are treated like crap by many systems. I always built a system that I knew I would want if I had that job.

Access, VBA, and Excel are not good development tools, but without anything else at your disposal, you use them as best you can.

The list of Bill Berger Specials is long. Chorus was a single example, but the patterns and discipline I put into each one led to things that stood the test of time and didn't need constant refactoring and updating. Design well, with the full picture in mind, and the solution lasts.

PLACEMENTS PK id FK campaign_id status best_value CAMPAIGNS PK id name client AUDIT_LOG FK placement_id old_value changed_by

There's a word for what I do that isn't "shadow IT" and isn't "software engineering." It's craft.

A craftsman doesn't need permission to build something right. He doesn't need a CS degree to understand that code should be readable, that data should have one source of truth, that a system should survive the departure of its creator. He needs to care — and then he needs to keep caring long enough to learn the discipline that turns caring into structure.

Muffit cared. He built Macro1 because nobody else was going to solve the problem. But caring without discipline produces things that work once, for one person, on one machine. Caring with discipline produces Chorus — something that runs for years, serves a team, and doesn't need its builder in the room to function.

The Bill Berger Special isn't a hack. It isn't a workaround. It's the thing that should have existed in the first place, built by someone who got tired of waiting for the people who were supposed to build it. Access when Access was the right tool. VBA when VBA was all there was. SQL when the data outgrew the desktop. Python when the world finally caught up.

The tools change. The discipline doesn't.

And somewhere in a hallway at 5700 Wilshire, if you listen carefully, you can still hear Muffit.

"Mock Mock. Mock Mock."

Thank you. Thank you.

Rest easy, Muffy. Someone took it from here.

The Sequel

You needed a Bill Berger Special back in the day. I learned some awful things to build them — VBA, Access Forms, the Excel object model, various APIs that no sane person would touch voluntarily. I learned them because there was no other way. The gap between what the team needed and what IT would provide was filled by whoever cared enough to fill it, using whatever tools were lying around.

That era is over.

With disposable software, you can make your own Bill Berger Special and not share it with anyone but yourself. As long as it works for you, it works. You don't need to learn VBA. You don't need to understand the Excel object model. You don't need to beg IT for a database. You need a new interface — an AI — that is just like another person sitting by your side. Super fast. Infinitely patient. Knows every programming language ever written.

One catch: it has a horrible memory disease. Every conversation starts from zero. It's the guy from Memento, running forward instead of backward — solving your problem at full speed, then forgetting you exist the moment you close the window.

But that's fine. Because the thing it builds for you? That stays. That's the artifact. That's the new Bill Berger Special — except now, anyone can make one.


Bill wrote the story, the dialog, and the argument. Claude drafted the connecting prose, explainer boxes, and illustrations. Both are woven throughout — meat and glass.

Disclosure: co-written by Bill Berger and Claude (claude-opus-4-6).

← The HLLAPI Stare  ·  YOU++