Jurassic Park, published in 1990 and later adapted in a blockbuster movie in 1993, is an exhilarating story of pushing the boundaries of science without regard for the outcome. At its heart, it's an examination of the hubris of humankind. In almost every aspect of Jurassic Park, corners are cut and expenses are spared.

To many, the 1993 movie is the definitive version of Jurassic Park. In fact, many people–including myself for most of my youth–are unaware the movie is based on a book. The novel explores the same themes with more depth. Lengthy conversations reveal all the mistakes John Hammond made when developing the park, as well as their disastrous outcomes. While the novel can be dense at times, it is a rewarding endeavor with a number of lessons that can be applied to the real world.

After a recent rereading of Jurassic Park, I found a lot of it rang true to my current career as a programmer. The big lessons should be obvious to most: be thorough in your project planning to ensure all your bases are covered, hire the right people when needed, and manage your expenses properly. However, there is a particular scene in the book not present in the movie that has helped me understand an incredibly important aspect of programming: real-world variables.

Early on, the group invited to Jurassic Park take a tour of the inner-workings of the park. Part of this tour includes the sophisticated system put in place to track the dinosaurs. Through a combination of motion detection and visual imaging, they are able to get a consistently accurate reading of the current number of dinosaurs present in the park: 238. Since the dinosaurs are man made, the minds behind the tracking system know exactly what to look for if anything changes, e.g. a dinosaur dies.

As the story progresses, our heroes find evidence that indicates the dinosaurs are reproducing, a feat that is seemingly impossible for a female-only population. Dr. Ian Malcolm, portrayed by the charismatic Jeff Goldblum in the motion picture, is not convinced the tracking system is producing an accurate number. When he pushes them to increase the number of animals to search for, they eventually see 238 jump to 292.

How did a mistake like this happen? To quote Ian Malcolm, “you only tracked the expected number of dinosaurs. You were worried about losing animals, and your procedures were designed to advise you instantly if you had less than the expected number. But that wasn’t the problem. The problem was, you had more than the expected number.” To put it simply, they designed their program to track the number of dinosaurs based on their own expectations.

Designing based on your expectations is a pitfall many programmers fall into. Sometimes it results in a family of bloodthirsty raptors or, in less extreme cases, compromised data. Since we’re all still patiently waiting for a real Jurassic Park, let’s look at a more applicable example. Say you are tasked with building a payment form that allows the end user to conveniently make payments. You put together a basic form with a submit button. Seems simple enough, but what happens to that submit button while the payment is processing? You know to wait patiently, but a user might start slamming the button in hopes that it speeds up the process.

Did you account for the impatient user who just processed their payment four or five times by disabling the button after the processing begins? For many, the thought might not have crossed their mind. In all your testing, you always press the button once and wait, but much like the ecosystem in Jurassic Park, users are unpredictable and often behave erratically. It’s important to keep this in mind when programming. At every step, you should be trying to break your program because, more often than not, someone else will, and the outcome could be disastrous.

Jurassic Park remains a cultural icon, not for its action-packed set pieces featuring dinosaurs, but for its examination of human error on a catastrophic scale. It’s easy to gloss over some of the finer details when planning a project, but those details could have major consequences. As a programmer, you should always be aware of this and doing what you can to account for every variable. You never know when one of those variables might come back to bite you in the neck.