3 Ways Feature Flags Could Have Saved Jurassic Park 
Tags: continuousdelivery, continuousdeployment, featureflags
Published: 2022-10-05 03:37:16

---
title: 3 Ways Feature Flags Could Have Saved Jurassic Park 
published: true
date: 2022-09-22 17:37:42 UTC
tags: continuousdelivery,continuousdeployment,featureflags
canonical_url: https://www.split.io/blog/3-ways-feature-flags-could-have-saved-jurassic-park/
---
![Dinosaur on dark background](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uvhpwy4a98r1sjvjl5of.png)
Do you find yourself saying “hold onto your butts” every time you release a feature? You wouldn’t be the first. Samuel L. Jackson’s character said this iconic line in Jurassic Park prior to forcing downtime to fix a release-gone-wrong. Thankfully with Feature Flags, your release won’t set dinosaurs loose into the world to feast on lawyers (Will it?), but it may feel nerve wracking nonetheless. 

If Jurassic Park taught us anything, it’s the power of a developer over your infrastructure. Would we even have a movie if it wasn’t for the lack of checks and balances when Dennis Nedry felt overworked? 

If I may quote a Redditor; “Jurassic Park is a disaster movie about IT management, that just so happens to feature dinosaurs. Who hired a single developer for that entire park? Single point of failure for your entire system? Who did the code review that let such an obvious virus into the system? What about easy disaster recovery and rollback? It’s a brilliant example of how ‘not’ to run a dev project.”

This comment got me thinking: What if the software team at Jurassic Park used feature flags and measured the impact of every change they introduced? Would the park have thrived versus leaving the humans fighting to survive? 

The equation for this movie is: 1 developer + 1 major release = 1 mega meltdown that’ll cost you an arm.

Many would say Jurassic Park was actually a movie about ineffective (or dangerous!) deploy and release strategies. If Jurassic Park didn’t go live with one big haphazard release, the plot may have taken a different turn. If the team had the ability with Feature Flags to flip a kill switch, assign specific segments for the Dino DNA room, and track small changes – maybe we’d be petting dinosaurs on our next PTO. Instead, we’re checking our side mirror for large objects. 

The real hero of this movie was teenage hacker, Lex, who finds a way to reactivate the park’s security system after the ‘virus release.’ They’re in luck, “It’s a UNIX system, I know this!”. Thanks Lex, but the downside is downtime. Downtime isn’t only bad when you’re running from dinosaurs, it’s bad for business. In fact, 44% of enterprises indicate that hourly [downtime costs exceed $1-$5 million.](https://www.split.io/blog/4-feature-flag-cost-efficiencies/) That can take a dinosaur-sized bite out of your budget pretty quickly. 

Stop fearing catastrophic outages. Here are 3 mistakes Jurassic Park made, and how Feature Flags can help you easily avert a potential disaster. 

**Mistake 1. A bug, whether encased in amber, or your code, can cause major issues.**

With feature flags, you have easy access to a kill switch if and when that bug’s dino DNA finds uhh… a way to ruin things. What’s even better is you can automate your kill switch. Good news if your engineers are on lunch break, or were already on the lunch menu of a hungry dinosaur.  

Check out how to [automate your kill switch](https://www.split.io/blog/automate-your-kill-switch/). Also, don’t let rollbacks breathe down your neck like a raptor coming at you from both sides, get rid of rollbacks with [feature monitoring](https://www.split.io/wp-content/uploads/2022/07/GetRidOfRollbacksWithFeatureMonitoring.pdf). 

**Mistake 2. Letting raptors test your releases.**

The raptors were testing fences more than Nedry was testing his code. So how can you test as diligently as raptors finding weaknesses in electric fences? Test in production. Split makes testing in production possible with feature flags. Control your code by targeting only a limited set of users to changes, with automated alerts to identify defects if they happen. Although Nedry purposely introduced a virus, he could have segmented his virus ridden release to a smaller lab sample. That way he wouldn’t have faced the unintended consequences of fences unlocking and having a faceoff with a Dilophosaurus. 

Check out how you can [test in production](https://www.split.io/solutions/test-in-production/) and download [Feature Flag Best Practices](https://www.split.io/feature-flags-best-practices-ebook/). 

**Mistake 3. The bigger the better – wrong for dinosaurs and for releases.**

T-rex sized releases can be deadly. To safely and rapidly deliver products or dinosaurs that keep pace with evolving customer needs, we need to turn to [feature delivery](https://www.split.io/blog/feature-delivery-unlocks-speed-safety-and-business-impact/). Check out what [enterprise engineering manager, Matt](https://youtu.be/NYE2UNeJv6k), has to say about worry-free releases.

**BONUS TIP: Don’t let your development teams burn out like Timmy on an electric fence!**

With less on the line using small releases and monitoring results, developers can rest easy. No more saying ‘nuh uh uh’ to a Friday release. No more on call. With Split Feature Flags, you can get back to what you love. Maybe that’s rewatching Jurassic Park for the millionth time like this Director of Marketing. 

By the way, Samuel L. Jackson’s character Ray Arnold wasn’t able to bypass Nedry’s security. But if you think you can do better, you can try your hand at hacking Nedry’s system [here](http://jurassicsystems.com/).