Last month I attended IBM’s 10th Annual [Steve] Mills event, when industry analysts converge to hear what Software Group has been up to, and where its going. There is always a ton of content, which makes it hard to summarize, so I won’t even try. But there are a couple of key narratives I want to capture, and I will use separate posts for them.
The first narrative is Get Simple.
Generally IBM doesn’t understand simple. IBM likes to create systems that are infinitely configurable, to meet every possible “need” that an enterprise might ever think of. As I like to say: IBM never met a requirement it didn’t like. But configuration is expensive – it requires consultants (go IGS!) and a lot of time and unnecessary pain.
I had a number of conversations at the Mills event however, which indicated IBM is getting a feel for the new simple. Rather than telling customers they can have all their old complexity and cloud operations too IBM is going to start being opinionated about system images. One of the first IBM products built to this way of thinking is the new Intelligent Operations Center, used as the basis for IBM Smarter City and water management plays. Customers can basically acquire the IOC in four different versions… large on-prem, large SaaS, small on-prem, small SaaS, and that’s pretty much it. But more products are likely to take the same approach.
When I have spoken to IBM Distinguished Engineers and senior managers in the past they have tended to believe that complexity could be abstracted, but after the failure of models such as Ensembles, it seems a new pragmatism at work. I talked to Jason McGee and Rob High, both DEs, and they both talked to the new simplicity as a better way of doing things.
IBM of course isn’t the only one with the config problem – its practically definitional for Enterprise software. In 2006 I said “Microsoft servers are a configuration fetishists’ wet dream”.
Unlike the enterprise however the Web thrives on simplicity – certainly on the config and operations side. Ruby on Rails, the favorite framework of many web developers, is based on a core concept – Convention over Configuration.
The idea is summed up pretty nicely here:“Design a framework so that it enforces standard naming conventions for mapping classes to resources or events. A programmer only needs to write the mapping configurations when the naming convention” fails.”
Or in my rambling fashion:
Ruby on Rails is interesting because it forces constraints on developers… and they like it.
Rails is about freedom in the Kantian sense-development has a categorical imperative – what you do should be morally applicable to anyone else in the same circumstance. Its about responsibilities rather than rights. The responsibility to ease of use.
Abstractions are aspects or constraints of the framework itself, rather than veneers to hide code behind and allow ever more configurations to be applied. Freedom comes from accepting and working within constraints. Beautiful code comes from limitations, not being able to configure everything in sight.
A related way of thinking is lesscode.
lesscode.org is a place to advocate, discuss, and practice the art of using less code to get more done. We shun complexity and challenge the status-quo when it impedes our ability to simplify our development tools and processes. We appreciate Python, Ruby, LAMP, REST, KISS, worse is better, and talk like a pirate day.
Back in 2006 (that year again!) I asked David Heinemeier Hansson, inventor of the Rails framework, if lesscode also meant less maintenance. He was good enough to offer a thoughtful response, which I will include in full.
“So my experiences would tell me that conventions of reward (“do it like this and you’ll get that for free”) has a really long shelve life. I remember when I worked in PHP, I would always tweak the configuration approach a tad going from app to app. This would lead to the code base of the previous project feeling really old really quick.
Rails applications don’t suffer from the same notion. Yes, we keep adding features and tweaking APIs to make the common stuff easier, but the majority of core conventions has been stable for a very long time now. It gives all applications a common culture and fix point.”
Java culture (more JAR JAR, more WAR WAR) is a long way from Rails culture, though early Spring (and latterly Roo) made some valiant efforts to make Java more of a convention oriented system for development.
Now I don’t want to go down a Rails is more maintainable than Java rathole, especially because Web Companies seemingly turn into Java shops when they grow up (Twitter, for example, recently took a seat on the JCP). As Eric Baldeschweiler, founder of Hortonworks and the guy that hired Doug Cutting to build Hadoop for Yahoo, told me recently he learned to love Java precisely because it allowed Hadoop to evolve, because of its maintainability.
But its inarguable that reducing configuration options makes support and maintenance easier. You can’t automate your way out of complexity.
That’s the real lesson of the web. How does Twitter support a user population of hundreds of millions of people with such a small ops team? The answer is limiting the range of deployment options in terms of servers. The same is true of any of the major web firms.
As I wrote recently, VMware seems to understand this trend lessons of the web: on vmware, cloud and what comes next. I have to say its good news to see another client, in the shape of IBM, thinking the same way. The Web can teach the enterprise something about Cloud Computing – after all, that’s where it came from, right?
Am I saying that all IBM products are now easy to install? Of course not. This will be a multiyear effort with missteps along the way. But consider- when you build a new data center you don’t retrofit it with a bunch of old intel gear. You build out for scale, with the latest hardware. That’s the kind of model we need to move to in software.
As much as anything, I think its worth calling out that IBM is thinking this way.
IBM is a client, and paid T&E to the Mills event.
