The cost of change

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.