Around a year and a half ago, I coined "Gottlieb's law," which I suppose should officially be a theorem because it has not been conclusively proven. It certainly hasn't been disproved though. Because I will probably never be able to prove that "a company's success in content management is inversely proportional to the amount of information that is exchanged over email," I figured I would move on with a new theorem. Here goes:
Gottlieb's 2nd Law (or theorem)
Novelty + Urgency = Chaos
This comes from an observation that when companies put a development team (or any other kind of team) in a pressurized environment and give them new technologies and tools to work with, chaos ensues. Developers don't have time to learn the new platform so they hastily try to apply legacy practices and ideas which are not necessarily appropriate for the new technology. To make matters worse, this chaos is difficult to work out of the system even after developers have learned better. Time simply hasn't been budgeted to go back and correct the mistakes that were made. Sometimes known bad habits are even repeated just for consistencies sake.
Here is how it usually plays out in the world of web content management. A company buys a new CMS and intends to migrate 50-100 sites onto the new platform. The team takes a deliberately cautious approach of choosing the simplest example as a starting point/test case. After an easy experience building out the pilot site, the team writes out a migration plan that begins with the biggest site (who has been clamoring to be early because they are feeling real pain on the old platform). Before long this project blows up. The additional complexity of the larger site was not adequately accounted for in the project plan and the team is falling behind. Their unfamiliarity with the new API causes them to write hacks and work-arounds for features that are well supported by the platform - if only they knew how to use it. The longer the delay, the greater the pressure that squeezes out general practices like refactoring, code review, unit testing, and even communication. When a developer makes a new discovery, he will maybe apply it to new code but is rarely able to go back and fix sloppy, inexperienced code.
The first big site is delayed but that doesn't mean that the original migration plan is abandoned. A new development team is spun up to work on the next site. Of course, these guys are new to the platform. The seasoned developers are too busy with their death march to release the first site to share what they learned.
The new team either uses the first site as a model or tries to do everything the opposite way. The same things happens for the next couple of sites so every site is built in a different way and it is impossible to maintain them. Three years later, when the CMS is replaced, poor manageability is cited as a primary reason for moving off the platform. The chaotic condition of the code base and content makes the next migration harder. And then cycle continues.
How could this be avoided? It is not so easy. Usually a CMS purchase is supported by a business case that needs to be optimistic about both cost and benefit in order to get the ROI to look right. This innocent little exercise of telling a story that the management wants to hear is where the problems begin. Maybe it would have been better to explore the option of upgrading and refactoring the current platform and comparing the ROIs of the two approaches. Both migration and upgrading are complicated process that are full of surprises.
The next error is the assumption that building out sites will be like turning a crank. It may get that way eventually but the first few are as hard as building custom software. There are lots of choices and lots of places to make mistakes. Ideally, the sequence would be: (tiny) pilot site, medium site 1, rebuild medium site 1, build re-usable components and patterns, build a reference implementation based on the rebuilt site 1. After that the rest of the new sites can be built on a reference implementation that gets gradually improved as new ideas are tried out.
Whoever is holding the budget is cringing right now. Not only is this making more migration work (two+ additional sites), it is lengthening the time to benefit for the most important sites that may be funding this whole migration in the first place. It also means paying developers to do things other than coding: documenting, teaching, learning, and recoding. As expensive as this is, the costs are trivial when compared to the price of doing it wrong and feeling the need to replace the system years ahead of schedule.
Another strategy is to work with a systems integrator who has a long track record of working on the platform you selected. Of course, this only works if a) the consultants you get on the team really know the platform and b) you didn't beat them down on price so they need to cut corners and work sloppily. You really need to trust the systems integrator and partner with them to achieve joint success. These trustworthy partners don't come cheap either because they tend to be honest and conservative in their pricing. At the end of the day you may save money but the initial price tag will be discouraging when compared with others who want to tell you what you want to hear.
Too often people tend the focus on migrating the content itself during a CMS implementation. Migrating the content can be messy if it needs to be cleaned up first but there are at least some possibilities for automation (or at least hiring cheap temps to manually copy/paste). Rendering and integration code, conversely, is not at all portable (except for CSS - write as much presentation code as you can in CSS) and can be a real challenge to translate to a new platform. Porting the code is most efficient when developers can take the time to learn the new platform and logically break down the site to leverage the technology's native strengths and best practices. When under time pressure, the tendency is to revert to comfortable old ways even if they are counter-productive. And the downward spiral continues...