Large software components - content management systems, workflow engines, ERP systems, CRM tools - promise much, but often seem to deliver less and with great difficulty. There sometimes seems to be some distance between what the product claims to do, and what it actually does. Sometimes it almost does what you need, but not quite. It may present a myriad of possibilities, but give no guidance as to the best path. Alternatively, it may promote one true way and punish those who need to take the highways and byways. However, all these types of systems have one thing in common - you have no choice but to use what's in front of you.
Recently, we (that's the corporate we) have replaced a large web application developed in-house over many years with an equivalent system developed atop a 3rd-party content management system of precisely the category described above. The project went live on 6 September, having slipped 5 weeks on a 9 month plan.
This talk is not about how wonderful our CMS is or how wonderful we are. Nor can it examine the reasons why the previous application was obsoleted, or how the substrate for the new development was chosen. Instead, we want to look at the obstacles presented by our content management system and of our own devising, and how we overcame them. From that we'll try to draw lessons that implementors on and (this may be wishful thinking) vendors of large software systems might do well to learn.
The "we" doing the presenting here is myself and m'water-polo-playing colleague James. The "we" who actually did stuff is everyone we work with. Working with large lumps of other people's code is something that lots of programmers have to deal with at some point in their career. After a bit of a wobbly start, we did eventually start to motor, and our new system did go live pretty much on time. We learned stuff. Lots of stuff. Hopefully we'll get a chance to describe and discuss some of it at the ACCU Conference 2010 next April.