Simplicity – It’s a confidence trick

My friend, foil and friendly adversary James Governor posted an blog entry today entitled “What if IBM Software Got Simple?

It’s an interesting and appealing topic. It was in some respects what got in our way last year, it was also what was behind the 1999 IBM Autonomic computing initiative, lets just make things that work. It’s simple to blame the architects and engineers for complexity, and James is bang-on when he says “When I have spoken to IBM Distinguished Engineers and senior managers in the past they have tended to believe that complexity could be abstracted”.

There are two things at play here, both apply equally to many companies, especially in the systems management space, but also in the established software marketplace. I’m sure James knows this, or at least had it explained. If not, let me have a go.

On Complexity

Yes, in the past software had to be complex. It was widely used and installed on hundreds of thousands of computers, often as much as ten years older than the current range of hardware. It was used by customers who had grown up over decades with specific needs, specific tools and specific ways of doing things. Software had to be upgraded pretty much non-disruptively, even at release and version boundaries you pretty much had to continue to support most if not all of the old interfaces, applications, internal data formats and API’s.

If you didn’t you had a revolt on your hands in your own customer base. I can cite a few outstanding examples of where the software provider misunderstood this and learn an important lesson both times, I would also go as far as far as to suggest, the product release marked the beginning of the end. VM/SP R5 where IBM introduced a new, non-compatible, non-customer lead UI; VM/XA Migration Aid, where IBM introduced a new, non-compatible CMS lightweight VM OS; and of course, from the X86 world, Microsoft Vista.

For those products a descision was taken at some point in the design to be non-compatible, drop old interfaces or deliberately break them to support the new function or architecture. This is one example where change brings complexity, the other is where you chose to remain compatible, and carry the old interfaces and API’s. This means that everything from the progamming interface, to the tools, compilers, debuggers etc. now has to support either two versions of the same thing, or one version that performs differently.

Either way, when asked to solve a problem introduced by these changes over a number of years, the only real option is to abstract. As I’ve said here many times, automating complexity doesn’t make things simple, it simply makes them more complex,.

On Simplicity

Simplicity is easy when you have nothing. Get two sticks, rub them together and you have a fire. It’s not so easy when you’ve spent 25-years designing and building a nuclear power station. What do I need to start a fire?

Simplicity is a confidence trick. Know your customers, know your market, ask for what it will take to satisfy both, and stick to this. The less confident your are about either, the more scope creep you’ll get, the less specific you’ll be about pretty much every phase of the architecture, the design and ultimately the product. In the cloud software business this is less of an issue, you don’t have releases per se. You roll out function and even if you are not in “google perpetual beta mode” you don’t really have customers on back releases of your product, and you are mostly not waiting for them to upgrade.

If you have a public API you have to protect and migrate that, but otherwise you take care of the customers data, and as you push out new function, they come with you. Since they don’t have to do anything, and for many of the web 2.0 sites we’ve all become used to, don’t have any choice or advance notice, it’s mostly no big deal. However, there is still a requirement that someone that has to know the customer, and know what they want. In the web 2.0 world that’s still the purview of a small cadre of top talent, Zuckerberg, Jobs, Williams, Page, Schmidt, Brin et al.

The same isn’t true for those old world companies, mine included. There are powerful groups and executives who have a vested interest in what and how products are designed, architected and delivered.  They know their customers, their markets and what it will takes to make them. This is how old school software was envisasaged, a legacy, a profit line, even a control point.

The alternative to complexity is to stop and either start over, or at least over multiple product cycles go back and take out all the complexity. This brings with-it a multi-year technical debt, and often a negative op-ex that ,most businesses and product managers are not prepared to carry. It’s simpler, easier and often quicker to acquire and abandon. In with the new, out with the old.

Happy New Year! I Need…

2 Responses to “Simplicity – It’s a confidence trick”


  1. 1 james governor January 4, 2012 at 6:10 am

    agree with all of this. but what’s IBM’s alternative – wait for a resurgent Dell to supply the coming enterprise build out in terms of cloud style management? 😉

  2. 2 cathcam January 4, 2012 at 8:12 am

    My point was this, and it wasn’t actually aimed at IBM, or equally it applies to both IBM and Dell, HP et al.

    That software simplicity from an engineering perspective is really knowing and understanding what it will take to deliver. In that way you can simplify down and remove the need to provide endless options that can be changed this way and that way. It creates a UI for a customer with a very specific view of how the product will be used, by whom and what for.

    Without this, then what is simplicity?

    A good model for simplicity might be the Apple i-platforms. They own pretty much the complete stack and dictate how it’s used, what it runs on, and to a large degree. Compare that to the WIndows, x86 alternative, drivers, firmware, OS, Virtualization… ahh smell the complexity, configurability options.

    An alternative for IBM and Dell, BMC etc. is to build alternate products streams which start out more like cloud offerings, removing the options, the configurability. Deployed in the cloud this is easier to do. Sold as products, not so much, as it incurs the technical debt discussed earlier. Maybe catch-up soon, I’m headed back to London, long story, not a good reason.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




About & Contact

I'm Mark Cathcart, formaly a Senior Distinguished Engineer, in Dells Software Group; before that Director of Systems Engineering in the Enterprise Solutions Group at Dell. Prior to that, I was IBM Distinguished Engineer and member of the IBM Academy of Technology. I'm an information technology optimist.

Blog Stats

  • 82,839 hits

Subscribe to updates via rss:

Feed Icon

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 586 other followers

Top Clicks

  • None

%d bloggers like this: