Over the last year, my team and I have created a single-source-of-truth
accounting for the Software Engineering program at The Flatiron
School built on AirTable. I believe this system offers a superior
means for managing curriculum development, documentation, and collaboration.
I’ve written a series of posts documenting this solution that starts here.
The audience for the full series is fellow-educators or content-production
pipeline managers. In this post, I’ll provide an introduction to the problem at
hand.
Thanks
Let me express thanks to our executive sponsor, my boss, Brian Tobal as
well as my staff: Jen, Maxwell, Mohawk, our previous collaborators Jason and
Daniel. Let me also thank the countless issue-reporters or pull-request authors
that helped along the way. It was Brian’s faith in the idea of “modular”
curriculum and support for it at the organizational level when the ROI was
murky that gave us the time to prove the payoff to our convictions.
I believe that the secret to designing thoughtful educational experiences as
well as teams that design them is building a robust artifact that I call an
accounting.
“The Accounting”
An “accounting” can be grasped by this graphic:
Knowledge Graph AccountingItalian CookingItalian CookingPastaPastaItalian Cooking->PastaMeatsMeatsItalian Cooking->MeatsPasta FoundationsPasta FoundationsPasta->Pasta FoundationsSauce FoundationsSauce FoundationsPasta->Sauce Foundations......Meats->...How to boil waterHow to boil waterPasta Foundations->How to boil
waterHow to drain waterHow to drain waterPasta Foundations->How to drain
waterHow to assess pasta readinessHow to assess pasta readinessPasta Foundations->How to assess pasta
readiness
To translate into words, the accounting:
documents the binding between atomic student capabilities ("Learning Goals") and macro-objects ("Lessons") or nth-order macro-objects (e.g. "Unit", "Modules", or "Products"), and
calculates the chain of dependencies for any given capability that includes its recursive dependencies back to first principles (i.e. transitive dependencies)
The Accounting An “accounting” can be grasped by this graphic:
Italian food graphic
To translate into words, the accounting:
documents the binding between atomic student capabilities ("Learning Goals") and macro-objects ("Lessons") or nth-order macro-objects (e.g. "Unit", "Modules", or "Products"), and calculates the chain of dependencies for any given capability that includes its recursive dependencies back to first principles (i.e. transitive dependencies) In a textual format, this graphical accounting above might be rendered as:
Textual description of an accounting "Italian Cooking" would contain "Pasta Foundations" and "Sauce Foundations" "Pasta Foundations" would itself contain: "How to boil water" "How to drain water" "
Having defined what an accounting is, we recognize that the undertaking is considerable for an organization which maintains even a small set of knowledge assets. Given the investment that will be put into making the accounting, we should be very clear on the benefits that will be seen on the other side. In this section, we’ll identify large-scale goals that the accounting helps achieve. Subsequently, we’ll personalize those large-scale goals within the context of certain job functions in the next section.
To Facilitate Educational Dialogue The accounting gives the learning organization better tools for organization and communication.
Students might ask: “Why must I repeat ‘Pasta Foundations’?
Introduction Creating a curriculum accounting is a non-trivial amount of work.
Optimally, it should be the starting point of a curriculum. In my experience, however, it rarely is. Its lack is generally discovered as an afterthought when operational challenges and scale reveal gaps. These challenges and gaps mount up like debt (similar to developers’ “technical debt”), demanding more and more operational resources until they stifle execution speed. Invariably, this will occur at a critical and inconvenient time. Then the accounting is noticed missing, lamented as such, and must be built (under duress) to pay down the debt that’s been rung up.
In the previous post in this series, we concluded by recognizing several interactions our stakeholders need to undertake with our accounting. In this post, we’ll use their interactions to derive criteria for finding an appropriate IT solution for providing an accounting. We’ll see that neither simple, fast, and cheap spreadsheets nor standard databases (without extensive customization) are fully satisfactory. We conclude that the SaaS product AirTable provides the right mix of power with accessibility.
As a warning, several product- or technical-workflows are demonstrated in the next few paragraphs. This is for those who desire extra assistance in understanding the workflow overhead occasioned by a spreadsheet or the PostgreSQL database system.
AirTable Scoring AirTable scores like this:
Permit cycles (1) Permit calculated attributes (3) Changeset support (2) Schema changes are easy and cascade easily (3) Self-Documenting (3) Data can be delivered natively in a variety of views (3) Data is readily accessible to non-technical staff (3) Data is readily updated by non-technical staff (3) Price (2) Total: 21
Wow! Look at that total. Doubling and nearly tripling the points scored by our other two solutions! In the next post, I’ll explain how AirTable innovates out of this functionality gap.
Databases Scoring Let’s apply the same rating standard:
Permit cycles (1) Permit calculated attributes (1) Changeset support (0) Schema changes are easy and cascade easily (1) Self-Documenting (0) Data can be delivered natively in a variety of views (0) Data is readily accessible to non-technical staff (1) Data is readily updated by non-technical staff (1) Price (3) Total: 8
This ranking surprised me! “Since a database is a more powerful application than a spreadsheet, surely it should score higher,” went my thinking. While clean data might be compelling enough to opt for a database, its interfaces are poor and less-accessible which hurts it badly in our criteria.
Spreadsheets Scoring Permit cycles (1) Permit calculated attributes (1) Changeset support (0) Schema changes are easy and cascade easily (0) Self-Documenting (0) Data can be delivered natively in a variety of views (0) Data is readily accessible to non-technical staff (2) Data is readily updated by non-technical staff (2) Price (3) Total: 9
When considering a data modeling question, one will rarely go wrong by opting for a simple spreadsheet as a first step toward a solution. After nearly 40 years of ubiquity, the low cost and near-universal comprehension of the UI/UX metaphors provide spreadsheets a compelling advantage.
Despite these advantages, a spreadsheet is unable to provide good controls in modeling the accounting’s complexity.
In the previous post, we saw that spreadsheets and databases are insufficient for rendering proper accountings that will make our internal and external stakeholders effective.
Spreadsheets have an accessible UI, but a poorly-structured model for managing data. Databases have a solidly-structured model for managing data, but their interfaces are inaccessible outside of a class of technical cognoscenti. In this post, I’ll demonstrate how AirTable provides a middle path.
Kathy Sierra once said that when your tool sucks, people say “This tool sucks.” When the tool is great, people say “I’m so awesome with this thing.” AirTable makes me think I’m very awesome indeed.
At the beginning of this document, I proposed that an accounting lets curriculum managers organize their teams, express logical dependence of learning goals and operate more effectively. I’ll give a brief taste of how AirTable helps us do exactly this at Flatiron Schol.
Map Products to Learning Goals Airtable’s UI features a “stacking” user interface. Thus you can navigate from Learning Goals to the Product (a collection of two intermediate macro objects, Lessons and “Bricks”) and vice versa. Here we are going from macro-level to the micro:
Demonstration of tunneling through an AirTable-stored accounting macro-to-atomic Here we see a Brick, “Recognizing and Processing Nested Data Structures to Insight” that is one of several comprising the Product “Prework.
Here are some bits of advice that I think will help anyone trying to model complex information systems in AirTable.
Pursue Referential Integrity Like You’re Building a Database Referential integrity is a powerful concept. You should build your “base” as if it were a database in Postgres, Oracle or similar. You want your records to live in one place only. If you need to get their data, do not duplicate it. Built a series of associated records and lookups.
AirTable lookup fields can go one “leap” so, occasionally, you might wind up doing something that feels a little…hack-y. Nevertheless, hacks can get improved but dirty, duplicate data denies deletion decidedly.
Peter Naur was undoubtedly a great computer scientist: Turing award
winner, co-creator of the influential Algol language, and co-inventor of the
Backus-Naur notation used to explain the options of programs and program
routines. The significance of Naur’s contributions are beyond reproach. One of
my favorite works of his is “Programming as Theory Building”.
However, the language, style, and approachability make this article
less-accessible, and that is a shame. In this post I’d like to humbly submit my
edit: “Programming as Theory Building 1.01.”