If you’re a fan of Jurassic Park, you may remember the iconic line, “spared no expense.” However, when it came to IT, John Hammond made some serious mistakes that still apply to tech today. This article will explore how Hammond’s choices impacted the park and how they can be applied to modern-day IT and software development. Get ready to journey from the prehistoric era to the digital age as we explore Jurassic Park’s mistakes.
Spared No Expense
John Hammond had a massive production and design team (dino-engineers) but got the lowest possible bidder for IT.
We know this because Nedry says, “You know anybody who can network eight connection machines and debug 2-million lines of code for what I bid for this job?” Which indicates a drive to the lowest-cost developer. There are many causes for this to continue, but one is that computer software development comes with an asymmetry of knowledge. It is hard for the payer to compare two different bids and know if what you are getting is different compared to the other. In this case, Hammond assumed that the cheapest one was as good as any other.
Only one single programmer knew the system and how to fix it.
Nedry could bid the lowest because he was the only employee. This sort of efficiency frequently happens in IT departments and software design in general. There are many benefits of a team:
- Diversity of thought promotes different ideas.
- Code quality because of mutual scrutiny.
- Increased Efficiency because the timeline doesn’t get blocked waiting for a single knowledge bottleneck.
- Coverage if anyone is sick or missing.
- Continuity if anything bad should happen to the only person who knows how the system works…
Grand Opening instead of Incremental Release (aka the “Big Bang release”)
Everything had to go live on the same day. Hammond jokes about how nothing worked when Disneyland opened. Ian says, “Yeah, but John, If the Pirates of the Caribbean breaks down, the pirates don’t eat the tourists!”
First, any Disney fan will tell you Pirates of The Caribbean didn’t open until years after the park opened. The reason is that Walt didn’t make the mistake that Hammond made. Walt ensured that enough customer experiences were open on the first day so that people could come to and enjoy the park.
For example, Walt was criticized for not providing water fountains when the park opened and only providing soda to park patrons. In reality, he made a priority call. He had limited plumbing resources and chose to ensure that the bathrooms were finished in time over water fountains. Hammond seemed unable to make these sorts of priority calls.
Disneyland was never meant to be done but added to over time. Disneyland started at only 0.25 square miles and has since tripled in size, while Jurassic Park started at 22 square miles. Hammond made the mistake of trying to have everything on day one.
This happens frequently in software where there is a list of upfront requirements. A lot of time is spent on planning and imagining everything that is needed, then a release date is set. The bigger the release the bigger the chance of failure. Hammond did not need 100s of dinosaurs, fancy rides, and a gourmet chef to open the park; he only needed 1 dinosaur and the world would have lined up to see it.
No code review, pair programming, or code source outside of what was running.
This one may be a little technical, but once Nedry locked out the system, why was the only way for Jurassic Park to come back online to talk with Nedry’s people from Cambridge? Nedry’s code should have been made visible to everyone within the company. Even if there wasn’t a team of developers working on the code, there should be a way for a developer to look at the code and figure out what the system is doing. In a pinch, you need to be able to rebuild and redeploy the whole system.
There was automation in the park but not in the build process of code. To maintain good software hygiene, it is recommended to frequently store code in a source control system such as GitHub. Such a system keeps track of changes made, along with their respective timestamps and authors. Besides, it can also perform additional scanning on each check-in and enable automated deployment. By using such systems, you can recover from any unforeseen issue by reverting to a previously known stable state.
Without good software practices, Jurassic Park had just as much of a risk of being taken down by a lightning storm or a big magnet as a disgruntled employee.
Only one power station for life-critical systems and no backup options.
In any critical system, you build in redundancy. Consider an airplane with multiple redundant systems to ensure there is never a critical failure during a flight. This is true in critical infrastructure and software systems. There should have been at least one additional power station and, ideally, local backups to the mission-critical systems like:
- Computer power backup and redundancy
- Software backup where it can run from a separate site
- Communications back up to the mainland
- Dinosaur fences
Not having manual backups for critical systems.
The fact that doors in the building wouldn’t lock without software shows an over-dependency on software. When software runs any critical system, there must be a way to get the work done without it running.
This happens today when there is a very automated system, but work grinds to a halt if one component breaks. Sometimes, it takes a physical cart to allow products to move within a factory as a workaround when a conveyor belt is down.
Final Thoughts
How could this have been foreseen? Well, there are lots of ways to provide failure management. One method is called a pre-mortem, or a process of assuming the project has failed and working backward to determine how to prevent it. More details are outlined in the Harvard Business Review here. As outlined in a previous article, they could have run some assumption mapping sessions with various departments. Or investors could have been more than a little concerned about a rich man with a brilliant idea.
Chalk X 
Leave a comment