There’s a habit in educational technology of celebrating how many tools we can chain together. The lesson lives in the LMS, the collaboration happens in a shared document, the reflection gets recorded in a video app, the submission goes to a portfolio platform, and an integration widget pulls the analytics back into the gradebook. Each link in that chain was chosen for a good reason. Taken together, though, they produce something I’ve come to believe is more likely to fail learners than to serve them, and to fail at exactly the moment a teacher has the least room to recover.
The App Smashing Trap
The practice has a name, app smashing, and it’s widely celebrated in our field. I understand the appeal. When it works, combining tools can produce experiences none of them could produce alone. What the celebration leaves out is the arithmetic, since every additional tool is another place for the lesson to break. Take the five-system lesson above: if any one of them has a network hiccup, an expired session, a changed API, or a few minutes of downtime, the whole experience can collapse, and the teacher standing in front of the room has no way to know which of the five did it.
The clearest thinking I know on this comes from outside education. Richard Cook, an anesthesiologist who spent his career studying how accidents happen in hospitals and other high-consequence settings, wrote a short paper in 1998 called How Complex Systems Fail. It has since become required reading in software operations, and it applies to a classroom stack more directly than most of what gets written about edtech. Two of Cook’s observations matter here. The first is that complex systems always carry the potential for catastrophic failure, and that the people operating them are nearly always close to it in time and space; disaster isn’t an exception waiting at the edge of the system but a standing possibility inside it. The second is that when a complex system does fail, there’s no single root cause. Failures require several faults to line up at once, each of them necessary and none sufficient on its own. The search for the one thing that went wrong, Cook argues, reflects a cultural need to assign blame more than a technical understanding of what happened.
Read that back against a classroom lesson that fell apart mid-period. The teacher blames the video app. The tech coordinator blames the district’s single sign-on. The vendor blames the network. Cook’s point is that they’re all partly right and none of them has found the cause, because the cause was the combination, and the combination was the design.
The Multiplication of Failure Points
In practice the failure points show up in a few recurring forms. Authentication is the most common. Every additional tool asks the learner to prove who they are, often more than once, and expired sessions, password resets, and single sign-on hiccups become daily friction rather than rare events. Data dependencies are the next. When tools pass information between them, any disruption in that flow cascades: work disappears, progress resets, duplicate entries appear, and nobody can tell which system holds the truth. Version changes are quieter and worse, because institutions rarely control when a third-party tool updates, and an overnight change to one app can silently break its connection to another. And every tool carries its own support path, so that when something does break, troubleshooting turns into detective work across several vendors, each of whom can plausibly say the problem is somewhere else.
None of these is dramatic on its own, which is Cook’s point. They’re the small, ordinary faults that a complex system always carries, and the design decision to chain five tools together is what lets them line up.
What Complexity Costs Learners
The cost isn’t only technical. Cognitive load theory, developed by John Sweller in the 1980s, describes working memory as a limited resource and distinguishes the load that comes from the material itself from the extraneous load imposed by how it’s presented. A learner who is spending attention on which tab to open, which login to use, and where the submit button went this week is spending it on something other than the content. Good interface design exists to reduce that extraneous load. App smashing increases it by design, because every added tool brings its own visual language, its own navigation, and its own mental model, and asks the learner to switch between them, sometimes several times in one lesson.
Two more costs follow from that one. The first is equity. In my work with rural districts, the learners least able to absorb a complicated workflow are the ones on the slowest connections, the oldest devices, and the least experience with the tools, which is to say the learners we should be working hardest for. A stack that assumes fast internet and fluent users quietly selects against them; I wrote about the bandwidth side of this in Low-Bandwidth Course Design. The second is the teacher. Educators already carry more complexity than their days can hold. When technology adds maintenance, troubleshooting, and re-learning to that load instead of removing it, the tools get abandoned, and often the abandonment is the rational choice.
What does intentional simplicity look like?
The alternative isn’t choosing worse tools so much as deciding where complexity earns its place and where it’s only adding burden. Two ideas have guided me here. One is calm technology, the principle from Mark Weiser and John Seely Brown that the best technology stays at the edge of attention and moves to the center only when needed. I’ve written about what that means for learning platforms elsewhere on this site, and its relevance to a five-tool lesson is plain: a stack that demands constant attention to keep running is the opposite of calm. The other is older and blunter. The KISS principle, keep it simple, stupid, is usually credited to Kelly Johnson, the Lockheed engineer whose team was asked to design aircraft that an ordinary mechanic could repair in the field with basic tools. The point wasn’t that simple is elegant but that simple is what still works when conditions are bad and the expert isn’t there. A classroom on a Tuesday afternoon is that condition.
Applied to lesson design, this comes down to a few habits: 1) start from the learning outcome and ask of every tool whether it serves that outcome directly or whether it’s there because it seemed interesting, 2) design for the context you actually have, the bandwidth and devices and support staff that exist, not the ones you wish existed, 3) plan for failure by making sure the core of the lesson survives if the supporting tool doesn’t, which is what web designers mean by graceful degradation, and 4) build in modules rather than monoliths, so that each piece can stand on its own when the connection between pieces breaks. The atomic design approach I’ve used for LMS templates (E-Learning with Atomic Design) came out of exactly that last need.
The single most useful test I’ve found is also the simplest. For any learning activity, try to accomplish it with one well-chosen tool. One isn’t always right, but forcing yourself to justify the second tool, and the third, surfaces how often they’re there for the designer’s satisfaction rather than the learner’s benefit. When a second tool is genuinely needed, prefer native integration over a third-party bridge, and remember that even native integration is a new dependency. Then, periodically, audit what you have and remove anything that isn’t earning its complexity. A reliable solution that does most of what you wanted beats an elaborate one that fails unpredictably.
The Bottom Line
Every piece of technology added to a learning experience should pass one question: does this make learning more accessible and more effective for the people in the room, or does it mainly make the designer feel sophisticated? Complexity isn’t wrong in itself. It should be a conscious choice that serves a clear purpose, and when we default to adding rather than subtracting, we usually end up serving our own interest in the tools more than our learners’ interest in learning.
I’ve watched too many educators burn out managing stacks that promised innovation and delivered troubleshooting. The next time you’re tempted to smash one more app into a lesson, ask what would happen if you reached the same learning goal with half the moving parts. Cook would tell you the failures you never see are the ones you designed out.
If you’ve pared a lesson or a stack down and seen what changed, I’d like to hear about it. You can reach me at licht.education@gmail.com, and there are more tools, articles, and resources at bradylicht.com.
