5 lessons Jurassic Park taught me about software development
By: Vineeth Venudasan
Tags: Jurassic Park, Software Development

This post will reference only the -original- 1993 movie. The sequels were unnecessary cash-grabs, and I will pretend they do not exist.

And don’t even get me started on the current trilogy.

Now that we got that rant out of the way, Jurassic Park having lessons for software development (or technology, rather) is pretty unsurprising, considering the movie was based off a novel by Micheal Crichton, who frequently used plots around technological advancements going wrong.

These are 5 things I personally picked up from the movie I believe applies to our careers as software engineers.

1. Just because you can, doesn’t mean you should

Ian Malcolm, a character in the movie berates John Hammond on the latter’s lack of foresight in using something as powerful as genetic engineering, and that they were handling it more like a “kid that had found their dad’s gun”. John Hammond, the creator of Jurassic Park retorts that Ian is not giving him and his scientists due credit; because “they have done what no other scientists have ever done before” To which Ian replies “yeah but your scientists were so preoccupied whether or not they could that they forgot to think if they should”

I use that last phrase a lot at work.

The reason being that a lot of the complications that we see on our software projects comes from an engineer or architect using something that they could do from a technical standpoint, but is often a bad idea practically. For instance, should the team use Cassandra on a e-commerce website to store orders and shopping basket items from customers? Well, obviously, it should work. But it probably isn’t the best tool for the job.

Some other examples :

i) choosing to do microservices too early in a project when a well structured monolith is all that is needed.

ii) using unnecessary tools / frameworks into our JavaScript projects

iii) using design-patterns to solve a problem, when they are not needed in the first place.

2. Clear, intuitive architecture (and) code-bases

Ellie Sattler is in the maintenance building at Jurassic Park all by herself trying to reset the circuit-breakers to the park. But first, she needs to find out where the main switchboard is. John Hammond is in another building is trying to help her do that over radio. He has a large complicated looking schematic diagram of the maintenance building in front of him, while Ian Malcolm is there right beside him. However, John soon finds out he had directed her to a dead-end in the building. Ellie is getting frustrated. Ian sees this, and he himself is annoyed at John for not considering a simpler idea he had earlier. He thinks this has gone on far enough, and grabs the radio from John’s hand. He tells her “look above you, there should a large bundle of cables and pipes all heading in the same direction. Follow that”. Soon after doing just that she reaches the switchboard.

A good architecture diagram, or code-structure is one that could be understood and navigated just as easy as that.

Keep your architecture simple and intuitive.

Using the right tools to represent that architecture is invaluable for your future team-mates. Also, simpler things like good package structure and code organization ensures that every new-comer on the project finds their metaphorical switchboard by just following those pipes going in the same direction.

I personally use the C4 model to represent architecture, and will always advocate for clean-architecture, and feature-based packaging of code in your projects.

3. Design for failure, and test them

For people unfamiliar with the story, the dinosaurs in Jurassic Park got free because a disgruntled employee had inserted a backdoor into the code and turned off all security systems guarding the dinosaurs.

John Hammond suggests that Arnold, the chief engineer of Jurassic Park’s IT systems shut down and restart the system, so that it brings the systems back to it’s original start up mode. This would be the state before the disgruntled employee had made his changes. Arnold vehemently disapproves. When John asks for a confirmation if the system will come back on to their original state, Arnold replies “Theoretically yes, but we have never shutdown the entire system before, it might not come back on at all”

They had never tested a recovery mechanism, a big one at that!

In the end, turning off the system and restarting it did bring everything back up, but it had unintended consequences that no one was aware of. If you watch the movie, there’s a couple of times the word “maybe” is thrown about in the dialogue around the event. No one knew what to expect when they restarted the system.

This is unacceptable for a software system in your company.

We must run through disaster recovery scenarios in our projects, so that in the midst of a firefight or a production issue, we know what works and what doesn’t.

Too bad the people at Jurassic Park didn’t. These unintended consequences I spoke about earlier causes the deaths of two more people in the movie, and almost got everyone else killed.

4. Smart hacks can have unintended consequences

In the beginning of the movie, the audience is informed the scientists at Jurassic Park were able to get DNA strands from dinosaur blood, but that it was incomplete, and had gaps in the DNA sequence. They were then able to fill these gaps with the complete DNA code of other animals like a frog. This solved the problem, and the scientists were finally able to grow a dinosaur.

Were they smart and got the job done? Yes. However, what they didn’t account for was the fact that it indirectly gave the group of dinosaurs (which were all genetically engineered to be female), the ability to reproduce asexually, just like some of frogs in west-Africa.

Often in our projects, we see a lot of teams pick out a “smart” solution to complete something as fast as they could, maybe due to project deadlines. However, more often than not, we miss an edge-case scenario, which then blows up later.

I usually avoid such solutions for the projects I work on, they’re often a landmine of sorts from my experience.

5. Start small and iterate

The only reason why John Hammond had invited visitors the park were to get them to “sign-off” on the park. This would enable his investors to continue putting in their money into Jurassic Park.

For this, John Hammond went on to offer all the visitors the entire tour that the park was to open with.

However, this exposed a lot more of their problems as the IT systems in Jurassic Park were not quite ready yet. For instance, the car took the visitors around the park had its headlamps being switched on all the time exhausting the car-battery, and not responding to commands. According to Arnold, this was “Item 151 on today’s glitch list”.

God knows what the other 150 problems were.

This made me think — wouldn’t there simpler user-flow that did not involve the systems that were not ready? Could he have showcased a fewer number of dinosaurs in a more controlled fashion, focusing on the bare minimum to get the scientist’s approval?

Could this have been the MVP that John Hammond needed?

Sometimes we as technologists fail to think of the minimum required to get our customers to be happy, and only then iterate and build on that solid foundation of customer satisfaction.

Prioritize value and quality over quantity.

Well, that’s all I had for now. I hope you enjoyed it. If there is anything you think I should add or clarify, please do let me know!