Folksonomies. Hula. REST. RSS. XMLHTTPRequest. What do these things have in common? Besides being hot to the point of borderline buzzword status? Simplicity, I would argue. Taken together – and these are hardly the only examples I could have chosen, I think they’re symbolic of a technology pendulum that is swinging back towards the simple over the complex.
While many of the arguments on behalf of such technologies are regrettably binary in their analysis – unreasonably asserting that simple’s the answer to every problem – I see the popularity of these simple technologies as merely technology pragmatism at work. Developers and users alike want to be productive, and simple technologies offer them the ability to do that with a relatively low learning curve and few if any barriers to entry.
These simple tools and techniques, in my estimation, are here to stay and are likely to expand their respective footprints rapidly over the next few years as their intrinsic malleability – one of the common byproducts of simplicity – allows them to be bent towards new and unforeseen uses.
What is less clear, however, is to what extent technologists higher up the developer stack can balance required complexity with beneficial simplicity. Many Java projects I’ve been involved with in the past, for example, suffered from runaway complexity. The scenario used to run something like this: application A has design requirements such that EJB might actually be necessary, application B does not. For the sake of “design consistency,” however, both applications are implemented as EJBs. You get three guesses as to how follow up applications C and D are implemented, and the first two don’t count.
The lessons of REST, RSS, etc to me are clear – and echo what Adam Bosworth has been telling us for a while now – design should be as simple as possible, but no simpler (great use of the Einstein line, JGWebber). Trends like tagging and simple network services are finally giving simplicity its 15 minutes of fame; we just have to hope that the Architecture Astronauts are willing to listen to the lessons it can teach us.
Fraxas says:
February 20, 2005 at 4:52 am
As always, the art is in defining what counts as "simple as possible". There's another Joelonsoftware link that's appropriate here — the article on leaky abstractions. In cases where the system's simplicity is hiding (abstracting away) the complexity of the underlying framework, you have to be really really careful in your design that you don't break the paradigm of the medium you're in by simplifying it out of existence. Joel's example of string libraries in C applies here, as does the lessons learned from RPC when RMI was implemented. It's *possible* to structure code such that remote calls look local, but in encapsulating away the (laggy, nondeterministic, potentially asynchronous) network, coders create weird and strange bugs that are the result of race conditions that RPC told them they wouldn't have to worry about.
That's one of the reasons I think Google's simplifications are working; you still need to click the button to go to the results page when you search. Even with Google Maps' fancy hidden IFrame, they're not trying to make the web feel like a local app.
sogrady says:
February 22, 2005 at 9:05 am
great great comment, Fraxas. i think your thoughts are spot on, particularly given that simplicity means different things to different audiences. to a developer, it means one thing – and has consequences to go along with the benefits. to a user, it has quite another meaning, and not quite the same impact.
but the single most important conclusion is what you led with: determining what simple means and how it should be applied is indeed an art, not a hard and fast set of rules, or – god forbid – a methodology.