Avoiding Being Eaten by a T-Rex: Why your Software Development and Deployment Process Should Matter

Recently my wife and I re-watched Jurassic Park. When I was a little kid, I used to believe that the tropical storm was the main reason for the power outage and problems on the the island befalling the guests. Now I know that the real problem was poor IT management and processes. Use some of these best practices to avoid being a raptor's lunch.

Could you imagine hiring this guy?:

Dennis Nedry is essentially a consultant. He doesn't know much about what goes on in the park, he's only hired to fix bugs, and he's given poor resources and poorly compensated. Giving someone like that access to
your production code is just a recipe for disaster.

Scheduled & Restricted Production Deployment - Your live environment should not be free to be updated by anyone at anytime. In a continuous update-release product you should schedule production deployments for a time which is least likely to interfere with other business operations and schedule other business operation at a different time from the release. For example, early in the morning bi-weekly would be a great time to update your dino park. No tours, feedings or events should be scheduled and the weather would be generally more cooperative. A designated and trustworthy pair of developers should perform the deploy together and perform the required testing afterwards.

Who's watching this guy?

Code Review - I have a feeling that debugging the phones does not interrupt the security and power systems on the island. I also have a feeling that most people question the need to reboot those systems if they had a change log or diff for each release. A good practice is to generate such listing for each deployment and have it reviewed by a second party.  For larger changes or changes that present a problem to security, a more complete review should be performed. Also, tying into the previous practice, you should have a standard script or deploy method and any deviation should also be part of the code review process. A source control system would make finding changes easier.

One thing they did right was have source control.

Test Environment - Your development environment should never, ever be your production environment. I'm pretty sure if you are compiling and it affects the production system, you're doing something wrong. If you have a local development environment, you can run all your unit tests and make all your mistakes safely before you put everyone's life in danger.  You might not kill an entire population, like if you worked on a nuclear reactor, but you might lose important time or data. In a multi-developer environment it might be a good idea to have an individual development copy and a collective development copy. Adding an additional step in the pipeline, creating a test or practice environment, will help find errors in your deployment environment. Treat this as if you were doing an actual production deploy. If you're missing any files or there are conflicts, testing here will highlight them. Having a test plan developed for each change and running that test plan in each environment gives you the most robust management.

If you can make this you can make a simulator for your test environment.

Stakeholder Management - If IT is important to your organization, it is important to keep everyone involved on board.

Not as nice as I remembered.

Chastising your workers for "their own mistakes" of a personal nature is not a good way to keep morale high. Also, not keeping track of the progress of Nedry or properly educating him in the business side of the island was a lack of 2-way communication and fulfillment of business goals. If compensation becomes an issue, then it might be wise to consider other vendors or a different IT budget to prevent sabotage, poor performance or quitting.
"Dennis, our lives are in your hands and you've got butterfingers?". Sounds like he was important enough to be better managed.


Well I hope you learned enough to avoid becoming a snack. If you have any other best practices you use, leave them here.