1
0
14d
🤔 {question}
{!revealed ? ( ) : (A gentle guide through clever automation
Hello! Rob built something rather clever back in 2008, and I'm going to explain it to you step by step. Take your time with each section—click "Tell me more" if you want deeper explanation, or just move on when you're ready.
The key idea is simple: instead of writing thousands of things by hand, Rob made a system that writes them automatically from descriptions. Like having a very organised assistant who knows the patterns.
Imagine you have a recipe book, but instead of "add 2 cups of flour," some instructions say "add «AMOUNT» of «INGREDIENT»."
A template (recipe with blanks):
Dear «CUSTOMER_NAME»,
Your account «ACCOUNT_NUMBER»
has a balance of «BALANCE».
Rob's system stores these "recipes with blanks" in a simple table called MBI_SCRIPT. Just two columns: the recipe name and the recipe itself.
The clever bit is that these recipes aren't just for letters. The same approach works for creating database tables, setting up data processing jobs, generating reports—anything that follows a pattern but with different specific values each time.
A chef doesn't write out the full instructions for Victoria sponge every single time—they have a master recipe and just note what varies. Same idea here.
If you need to send 10,000 letters, writing each one individually would take forever and you'd make mistakes. With a template, you write it once correctly, then the system fills in the blanks 10,000 times perfectly.
Also, if you spot a typo, you fix it once in the template, and all 10,000 letters get fixed. Much easier than finding and fixing 10,000 individual errors!
Now we need the actual information to fill in those blanks. This is stored in organised tables—think of them like very structured spreadsheets.
Customer information table:
| CUSTOMER_NAME | ACCOUNT_NUMBER | BALANCE |
|---|---|---|
| Mrs Smith | 12345 | £1,234.56 |
| Mr Jones | 67890 | £567.89 |
| Ms Patel | 11111 | £2,345.67 |
The system looks at each row and says: "Right, for Mrs Smith, I'll take the template and replace «CUSTOMER_NAME» with 'Mrs Smith', «ACCOUNT_NUMBER» with '12345', and so on."
This information doesn't have to be typed in by hand. It can come from other systems automatically—the bank's customer database, the design tools that architects use, spreadsheets that teams maintain.
The key insight: the information already exists somewhere. Rob's system just reads it from where it already lives, rather than asking people to type it again.
Because Rob's system reads from the source (rather than keeping its own copy), the next time it generates a letter for Mrs Smith, it automatically uses her new address. No one has to remember to update multiple places.
This is like how your phone contacts sync—change it on your phone, it changes everywhere. Much better than having separate address books that get out of sync!
Here's where it gets clever. The system has a small set of functions (like little workers) that do the actual work:
Get the list
"Who are all the customers I need to write to?" → Gets Mrs Smith, Mr Jones, Ms Patel
Get the details
"What do I know about Mrs Smith?" → Her name, account, balance, etc.
Fill in the template
Find each «BLANK» and replace it with the real value
Do something with it
Either show it (for checking) or actually run/send it
The entire "engine" that does this is only about 500 lines of instructions. That's remarkably small for something so powerful.
Think of it like a simple machine with just a few moving parts, but those parts can work together to produce incredibly varied results. A loom has a simple mechanism, but can weave infinite patterns depending on the threads and design you give it.
The simplicity is actually a feature—fewer things can go wrong, it's easier to understand, and it runs very quickly.
Here's something important: databases come with a built-in "library" that describes everything in them. It's like a library catalogue that tells you not just what books exist, but what chapters are in each book.
The database knows about itself:
These are called things like ALL_TAB_COLUMNS and ALL_TABLES. The "ALL" means "show me everything I'm allowed to see."
Rob's system uses this self-knowledge cleverly: instead of someone having to describe the database, the database describes itself, and the system reads that description.
This is profound. If you add a new column to a table—say, you start recording "email address" for customers—the database's self-catalogue automatically knows about it.
Rob's system sees the new column next time it runs and can include it automatically. No one has to update a separate list of "what columns exist." The truth comes from the source.
This is like how a library's computer system automatically knows when a new book arrives, rather than requiring someone to manually update a separate card catalogue.
If the database kept its structure secret, you'd have to maintain separate documentation that could get out of date. By being open about its own structure, the database becomes the single source of truth.
This philosophy—that systems should describe themselves and share that description—is actually quite unusual. Many systems hide their inner workings. Rob built on top of this openness.
You might wonder: "Is this AI?" It's a good question with a nuanced answer.
Like AI:
Unlike AI:
Modern AI (like me, Claude!) generates text by predicting what words probably come next. Rob's system generates text by mechanically substituting known values into templates. Both are "automation," but very different kinds.
An important insight:
Rob's approach is actually more reliable for many tasks. When you're generating legal documents, financial statements, or database structures, you want deterministic correctness—not creative interpretation. The boring, mechanical approach is a feature, not a bug.
Think of it this way: you want AI creativity when writing a poem, but you want Rob's mechanical precision when generating your bank's database tables. A typo in a poem is charming; a typo in a table definition might lose millions of records.
The two approaches are complementary. Modern AI could actually benefit from Rob's patterns—instead of trying to write perfect code from scratch, AI could learn which templates to use and what values to fill in, combining creativity with mechanical reliability.
Neither! They're different tools for different jobs. A calculator isn't "smarter" than a paintbrush—they just do different things.
Rob's system is like a very skilled craftsman with precise templates. AI is more like an apprentice who can improvise but sometimes makes things up. For building reliable infrastructure, the craftsman wins. For creative tasks, the improviser has advantages.
This wasn't just a clever idea—it was used to build real systems at major companies. The same small engine generated:
And because everything came from the same templates and metadata, they all stayed consistent with each other. Change a table definition in the metadata, and the system regenerates everything that depends on it.
The impact:
Work that would typically require a team of 20 people could be done by one person with this system. Not because Rob worked 20 times harder, but because the system did the repetitive parts automatically, freeing Rob to focus on the patterns and logic.
Companies like ABN AMRO (a bank), AstraZeneca (pharmaceuticals), and Liberty Global (television) used systems built with these patterns. These aren't small projects—they're enterprise-scale data infrastructure.
The fact that one person could deliver what normally takes large teams isn't magic—it's leverage. The same way a crane lets one person lift what a hundred couldn't, this system lets one architect build what would normally need armies of developers.
Rob built this in 2008. Since then, the tech industry has released many "new" tools—but most of them ask you to write things by hand that Rob's system would generate automatically.
What modern tools still get wrong:
The key insight that Rob had—and that the industry largely missed—is that specifications are data too. They should be managed, transformed, and served just like business data.
The principle:
Don't write by hand what can be derived from existing information. Don't maintain separate copies when you can read from the source. Don't repeat yourself when you can template.
This is actually a common pattern in good engineering: find the repetitive work and eliminate it. What made Rob's approach special was applying this to the entire data infrastructure, not just one small piece.
And by building on the database's openness (those ALL_* catalogues), the system stays up to date automatically. The database describes itself, the system reads that description, and generates accordingly.
Templates, not manual writing
Write the pattern once, fill in the blanks thousands of times
Import, don't retype
Read information from where it already exists
Use the database's self-knowledge
The "ALL_*" catalogues tell you what exists—use them
Small engine, big output
500 lines of code can generate millions of lines of results
Deterministic, not probabilistic
Unlike AI, it never guesses—same input always gives same output
That's it! Rob built a clever system that treats specifications as data, uses the database's openness to stay current, and generates reliable output through mechanical substitution. Simple ideas, powerful results.
Enjoying this? A quick like helps keep it online longer.
This content will be deleted in less than 24 hours. If you like it, you can extend its lifetime to keep it available.