Performing without Rehearsal: No Thanks
Would you perform in a play without any rehearsal? Perhaps if the play were a monologue on a topic you knew inside and out? Of course, I think even then, I’d practice my skit in front of a mirror or some friends and family. I’d at least try my luck with the dog or cat!
Preparation seems like a given, especially for large/important projects. In addition to preparing for something of importance or complexity, it’s always good to do a “dry run” to see how things will go. This applies to technical projects/tasks as well as things like performances in front of an audience. Odds are, you’ll have an audience; it just may be a horde of users for your system. It’s better to work out the kinks and automate as much of the process as you can.
So, imagine having to upgrade a piece of open-source software that your team heavily customized through several years of significant version releases. Suppose the client was afraid to allow you to perform any upgrades for years as they tacked on more and more customizations to the existing codebase. After all, it’s been working all this time. To make matters worse, suppose many of these customizations had to be made to the core code due to the youth of the version in-use. Now, finally, you are allowed to upgrade to the latest version. It’s going to be a nightmare, but you have a plan…in your head.
You know that a rehearsal is in order. In fact, there are so many things that need to be rewritten in order to work with the latest version of the customized software, you just know that problems will appear during the process. So, it makes sense to “perform” the “play” on the base software and database before any of that code is rewritten and re-integrated.
What Really Happens?
You know what really happens in this story; don’t you? Yeah, you do. The coding begins first. A fresh installation of the latest version of the software is used to rewrite all those customizations properly. Then, after a lot of effort is sunk into the coding, somebody thinks it’s a good idea to upgrade the data (no doubt this is huge amounts of data); the rehearsal.
The “performance” is a disaster! The data won’t upgrade; most likely due to all those customizations that slowly worked their way into the bytes somehow. Now you’re stuck with the old version of the software until you can figure out what is preventing the upgrade. There is way too much data to make it easy, so the process could take months, if your client even opts to bother now.
What’s worse? The coding for the upgrade is nearly finished! So, what if the client decides to cut-and-run on the upgrade? All that coding could be discarded; thrown away. Is it your team’s fault for not insisting on performing the rehearsal first? Is it the client’s fault for pushing hard to get the upgrade done and wanting to see their custom features in the new system quickly?
I wouldn’t be the one to answer those questions. I sure as hell wouldn’t be the one to say, “I told you so!” No, that would be a bad idea.
What’s the Moral?
Push hard for what you know to be the right path to a successful project; no matter what that project may be. Have I seen the above “story” happen several times in my career? Yep. Would I feel bad if I experienced the same again? Probably a little, but I’d feel a lot less remorse because I would shout about my experiences if necessary to be heard.
Decision-makers, listen to your experts. Clients, you are decision-makers, so the preceding fully applies to you. However, if you choose to ignore the advice of your experts, don’t expect them to sympathize with your plight. More importantly, please don’t make the ensuing backlash their burden to bear alone.