The Philosophy of Modular Code & Planning for Obsolescence
The other night I was listening to Jed Watson giving a talk about Keystone and he mentioned something that I had been thinking about lately and voiced a particular opinion on the subject that I strongly agree with. That subject was modularity, and the particular hypothesis/observation is what I will try to describe in this post.
Philosophy vs Code
What could this mean? One example springs to mind. Ember lead developer Erik Bryn has sometimes complained that people misconstrue Ember as being a monolithic framework. As he explained the code was all very modular and there was nothing stopping you from using one part and not another, except perhaps for a lack of documentation.
At this point I’d say — put your hands up if you are using bits and pieces of Ember? I’d be willing to bet that 99% of Ember developers buy into the whole package so to speak — because thats the Ember philosophy. Ember is built to manage your entire front end — with the hope being that this cuts through a lot of discoverability and compatibility issues and “just works”.
What this means is that while Ember (or Rails for that matter) may be built in a modular fashion for all intents and purposes they are monolithic framworks because thats how everyone uses them — philosophy matters. Thats why Ember’s response to React was to rewrite its own View rendering layer to be more React-like — Ember is a framework, and its designed to be used as such. As Bryn himself said when arguing against the idea of Ember as a monolith: “I consider it a failure if someone felt the need to swap things out”
Truly Modular Tools Are Ready for Obsolescence
This can be as much a source of frustration as amazement — perhaps it would be preferable if a new tool had to delete an old one from the npm registry Highlander style — “there can be only one.”
I think it goes without saying that anyone who throws their hat in the ring by releasing a new package/tool/framework wants as many people as possible to use their package. Perhaps early success more than anything else tempts some to expand the scope of their project, to try and grab more mindshare, more stars on Github etc. To become an indispensable and beloved part of every smart developers toolset.
However this nullifies one of the great advantages of small modules — disposability. A dependency that you depend on to a limited extent has the virtue of being relatively painless to replace. If that hip new library that everyone will be talking about tomorrow is actually useful, if it offers a genuine competitive advantage then its a much less daunting task to add it to your current project if you havent already married yourself to a honking big framework that wants to own your whole stack.
For that reason, one could argue that a responsible developer doesn’t seek immortality for their creation. Instead they should be aiming for something closer to a planned and painless obsolecence. A good package leads a quiet life, minds its own business, and, when it inevitably passes on, leaves the place nice and tidy for the new tenant to move in.
The King is Dead — Long Live the King.