English: Swarm of bees on bicycle (Photo credit: Wikipedia)
I came across this quoted text when reading the manual for Handbrake, a great open source DVD transcoding tool, and realized how relevant the wisdom continues to be…
There’s this old geek proverb:
The Law of Software Development and Envelopment at MIT:
Every program in development at MIT expands until it can read mail.
It also goes by the name Zawinski’s Law:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Guess what, though? We’re trying to avoid that kind of pointless bloat. HandBrake follows the Polyvalent-Program Pattern… We are following the *nix philosophy of small tools:
It is, however, all too easy to get sloppy about how large your shared context needs to be. The pressure behind Zawinski’s Law is the tendency of applications to want to share context for convenience. It’s easy to end up carrying around too much weight, too many assumptions, and to write programs that are over-complex, bloated, and huge. The paradigmatic example in the 1990s was the way that the mailto: URL induced the growth of huge mail clients embedded in Web browsers.
The corrective to this tendency comes straight from the old-school Unix hymnbook. It is the Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do—that is, when attempts to partition the problem have been made and failed. This maxim implies an astringent skepticism about large programs, and a strategy for avoiding them: look for the small-program solution first. If a single small program won’t do the job, try building a toolkit of cooperating small programs within an existing framework to attack it. Only if both approaches fail are you free (in the Unix tradition) to build a large program (or a new framework) without feeling you have failed the design challenge.
via IsIsnt – HandBrake.
This same advice could apply to your education technology ecosystem. Learning Management Systems have conditioned users to expect that every tool they will ever need for every task they will ever do should be provided as part of the LMS. They act like if it’s not part of the LMS, they can’t or won’t use it, forgetting that there is a whole universe of free tools designed to do one thing really well. Rather than wringing your hands that your LMS doesn’t have this one feature, explore which single-use apps have the best reputation for meeting that need, and give them a try. Often you will find that you can extend the capabilities of your LMS (if you want to look at it that way) by linking out to 3rd party tools.
In this day and age, the proliferation of free, focused tools for a variety of uses challenges each of us to become Sysadmins of our own Personal Cyber-Infrastructure. In other words, we all have to figure out our own internal rules and reasons for choosing certain apps to solve problems in our digital lives. While this means you’ll commit valuable attention and time to figuring out the optimal tools, the process will also make you a better computer user and you’ll develop a large background knowledge of which apps work best in a given situation.
We are working to move our university from total dependence on the LMS to experimentation with various 3rd party apps that can add value to teaching and learning. Thanks to Canvas’ focus on interoperability, any web tool that can produce a public URL can be piped into the LMS in a variety of ways. This means that your students and faculty can be free to explore whichever web-based tools fit their needs best, and there’s no pressure to make sure everyone is using the same tool. Even if it’s something as simple as mind mapping, note taking, video sharing, or voice threading, you can just provide the LMS as a central meeting space where all those tools can co-exist.
Related articles
Liked this post? Follow this blog to get more.
