When adpoting, do it often
A web page or a computer program can be seen as a complex adaptive system. Such systems have large boundaries, large edges or surfaces, with many contact points to the surrounding world. Through these points of contact the system interacts with the world. It gets input and it outputs output.
When changing a web page significantly, the number of visitors may drop, or visitors have trouble navigating. Or when an application is changed, users have to learn new, or maybe their old settings isn’t valid any longer. If it’s a library the users may have to change their code and re-compile.
When the system being the web page or program changes — the surrounding world (also systems) will have to change, adjust, to the new surface and interactions. Sometimes changes become large and cumbersome, for instance in the case of changing API’s in a well used code library. In these cases people tend to make these changes seldom and well thought through, and carefully weighting the value of changing against the cost of adapting. The effect being that more small changes will pile up in a big one, which will make the decision to go ahead harder… You get the point.
Instead of trying to do big changes seldom, one must do small changes often. Make the cost of migration small. Make the cognitive load smaller for the visitors of the changed page. The complex adaptive system should adapt, not be revolutionized. It’s the effect of the changes that are important.
The intuitive reaction to changes that require adoption is to do them seldom. Where we’re heading, where agile is pointing us, is to do it the other way around.
