You are here: Home Articles The cost of change
OpenID Log in


The cost of change

by Martin Aspeli last modified Aug 02, 2009 05:54 AM

Why better is not always a good idea

From time to time, we come across a situation in the Plone community where we had done something one way, and now there appears to be a better way. The "better" way is usually something new and exciting, like a new framework or pattern. Prominent recent examples include the choice of Zope 3-style browser views in preference over CMF style skin layer templates, or the use of viewlets over ZPT macros for re-usable page elements.

Often, there is (or at least, appears to be) a strong case for why the "better" way is indeed better. It may be faster, more flexible, or more maintainable. And sometimes, it may be seen as "easier" - easier to use, explain, understand.

But herein often lies a red herring. Easier for whom?

In many situations, what would be easier in isolation is not easier (or better) in context. A change that makes things a little bit better, or a bit less complicated, will have the opposite effect if it means that existing documentation (including books in print) is invalidated, or that existing users have to learn new ways. Worse, it's normally infeasible to root out all examples of "old" way from Plone and its third party products, which leads to further confusion. And sometimes, what seems like a good idea at first isn't such a good idea in the long run, as more nuanced use cases emerge.

To be sure, there are many situations where this cost is worth it and can be minimised. Ideally, the "old" way should continue to work and be supported, at least for a while, with the "new" way being encouraged where it makes sense. However, the cost needs to be considered from the beginning, not just after the fact.

I think there is a risk of some of this happening these days. For example, we've spent enough time putting in "new" Zope 3/Zope Toolkit technologies that it's now had time to become uncool in some quarters and for "new" ways to be mooted. And for sure, much of the pain that people have felt with Zope 3 technologies have come from over-use or over-abstraction, usually because the cost of change was not adequately considered. I know, because I'm as guilty of it as anyone.

So what can we do? There's no single answer, but a few rules of thumb may be useful:

  • People learn and remember better when there is consistency in concepts. This is actually one of the things I like the most about Zope 3/ZTK: there are a few unifying concepts that, once you understand them, stay with you throughout the framework.
  • A change requires twice as good documentation as something that's brand new. Good release notes that not only list the change by explains the rationale goes a long way. We also need "update guides" to explain how a change affects a user or integrator and how to get onboard with the "new" way.
  • Consider both the cost of change and the effort of bridging the "old" and the "new" way before asserting that a "new" way is better.
  • Think about how "deep" in the stack and how frequently used a component is when trying to assess the cost of changing it. The deeper it is, and the more prevalently it is used, the more difficult it is to predict the real cost of change.
Document Actions


Posted by BZ at Aug 02, 2009 08:57 AM
It is a good start to a long conversation. The greatness of Plone/Open Source is that they keep up with the times, if not blast forward pushing new technologies forward.

The con to that is for the support of production implementations, these upgrades and shifts in technologies can lead to hundreds of hours of learning, testing and migrations all of which aren't easy.

Hard to pick a middle ground, for me personally (and my company which supports 10+ plone sites) we usually just sit back a few releases behind (now on 2.5.2) and dip our toes now and again.


A good rule of thumb

Posted by at Aug 03, 2009 05:16 AM
A good rule of thumb (at least for other areas) is that it has to be an order of magnitude better in specs or convenience, not just a little better.

Some examples:

- CD wins over vinyl, because it's easier to transport, has new features that aren't available in the old format (skip to next song), etc. This is a case of the 10x convenience.

- MP3 wins over WAV files, because it's more than 10 times smaller.

- Windows Media / AAC do *not* displace MP3, since they are only 2x improvement on file size (and nothing on convenience), not 10x.

In a way, some of the changes in Plone 3 were more 2x changes — whereas what we're aiming for in Plone 5 is the 10x changes, changing how you manage content online, and offer an experience massively better than anything else that exists currently.

Of course, by the time we get there, it might be more like a 2x or a 5x improvement, but it will still be worth it so that other systems don't have the 10x improvement compared to your system.
Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up