I had the pleasure of listening to the awesome Jason Gary from IBM presenting on an internal conference call this afternoon, and he quoted Colin Chapman, the founder of Lotus (the car people, not the collaboration people):
"Simplify, then add lightness." That resulted in a microblog discussion on Joe Baxter’s Board with the equally awesome Luis Suarez on the topic, where I wrote: "Microblogging over blogging helps the simplification part. As does forwarding an e-mail and not including everyone on the original copy list "for completeness" – while adding a short precis of the key facts instead of expecting the recipient to read the whole thread adds lightness." We’ve been trying to adopt the Web 2.0 a philosophy of "simple" ever since we started on the social collaboration journey with Lotus Connections, but it is a constant battle because:- Every user wants their one, favourite feature added.
- Enterprise IT wants all the features of their existing, mature collaboration technologies carried over to the new one.
- Strategists want you to integrate with everything they already have to leverage their investments, while architects want the same to justify their previous choices.
- Marketing wants lots of new features to promote, in every new release.
- and Developers just love developing stuff!
As systems evolve, they inevitably get more complex. The challenge is to make them continue to appear simply to the users and to make deployment simple when the use case is simple.
At IBM we are often accused of over-engineering stuff. But fundamentally that is often because we build for deployment in enterprises with hundreds of thousands of users, data that is measured in petabytes and networks with millions (or billions) of endpoints. Apple shows how very complex technology can appear simple to the user. What interests me is how you lighten, so as to reduce maintenance costs and enhance evolution. Many years ago, I learnt as a participant in the Internet Engineering Task Force that it is easier to add new capabilities at the edge of a complex system – and hard to change the core. This principle of providing a generic core that supported innovation at the edge (when they designed the Internet no-one expected it to be used for Skype, YouTube and Facebook) helps to manage that complexity (and the ongoing story of IPv6 shows how hard to is to significantly change the core without impacting what is at the edge). This is the principle that the best development teams I have worked with try to adopt. Well architected, separable components built on well defined, open standards. Enable innovation at the edge, and minimise the size of the core. Manage complexity by layering architectures. Enable innovation by publishing all the interfaces (including all the ones you need internally, even if you do not know what external people are going to use them for). That way you can evolve complex organisms out of simple building blocks. Of course, that doesn’t make the final system simple – but if done well it should make complexity manageable. Albert Einstein said: "Everything should be made as simple as possible, but not simpler." Causing Joe to respond on his Board: Now THAT’S a great quote. Streamlining without "dumbing down". Perfect. The challenge is to figure out how simple it is possible to be, without either compromising its usefulness or compromising its ability to evolve at the edges to deliver even more value. I can’t really influence that. But I can start implementing simplification and lightening in the way I collaborate every day. This blog is a good example of the principle. The original microblog provided a simple discussion with some good sound bites for those who don’t want to dig into detail. But it can act as a "hook" to draw those that are interested into a blog post that investigates the topic in more detail. But I have to go now … I want to catch up on the discussion on Joe’s Board – and post a link back to this post for those who want to think about it a little deeper.