A tweet from Joshua Kerievsky (@JoshuaKerievsky) led me to the concept of design debt in programming. The idea is (quoting from Ward Cunningham):
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
I started wondering what the equivalent in learning design would be. Obviously, software design isn’t the same as learning design, though learning design could stand to benefit from what software engineers know about process and quality. For example, the Personal Software Process‘ focus on quality review and data-driven improvement could do wonders for improving individual and team learning design.
Similarly, refactoring to remove typical bad practices in programming could easily analogize to the reliable patterns we see in Broken ID. There are mistakes reliably made, and yet we don’t identify them nor have processes to systematically remedy them.
What are the consequences of these mistakes? It’s clear we often take shortcuts in our learning design, and let’s be honest, we seldom go back. For big projects, we might create iterative representations (outlines, finished storyboards), and ideally we tune them once developed, but seldom do we launch, and then reengineer based upon feedback, unless it’s heinous. Heck, we scandalously seldom even measure the outcomes with more than smile sheets!
For software engineering, the debt accrues as you continue to patch the bad code, rather than fixing it properly (paying off the principal). In learning design, the cost is in continuing to use the bad learning design. You’ve minimized the effectiveness, and consequently wasted the money it cost and the time of the learners. Another way we accrue debt is transfer learning designed for one mode, e.g. F2F delivery, and then re-implement it as elearning, synchronous or asynchronous.
In software engineering, you’re supposed to design your code in small, functional units with testable inputs and outputs, and there might be different ways of accomplishing it inside, but the important component are the testable results. Our learning equivalent would be how we address learning objectives, and of course first we have to get the objectives right, and how they build to achieve the necessary outcome, but then it shifts to getting the proper approach to meeting objectives. If we focus on the latter, it’s clear we can think about refactoring to improve the design of each component.
Frankly, our focus on process is still too much on a waterfall model that’s been debunked as an approach elsewhere. We don’t have quality controls in a meaningful way, and we don’t check to see what reliable mistakes we’re making. Maybe we need a quality process for design. I see standards, but I don’t see review. We have better and better processes (e.g. Merrill’s Ripple in a Pond), but still not seeing how we bake review and quality process into it. Seems to me we’ve still a ways to go.