10 Things Everyone Working in Software Delivery can Learn From Jurassic Park
Jurassic Park was one of the greatest movies of the 90s, a tour de force of marketing, technology, storytelling and acting. One of the things I am constantly reminded of in my day to day life working in software delivery is the quote from Dr Ian Malcolm:
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
To me this quote perfectly sums up one of the big things that everyone involved in software delivery needs to remember, yes we can do something, but should we do that thing? What value does it really bring? Are we just replicating an outdated process?
I started thinking about this a bit more recently and realised that there were a number of lessons we should all be taking from Jurassic Park, so here they are!
1. Always start with “Why?”
So to reiterate our introductory point — always start with why you are doing something, not how you are going to be doing it. This will likely save you hundreds of hours of pain and allow you to deliver a much simpler and easier to manage solution in the end.
I have worked with hundreds of businesses where someone wants something simply because that is how it works in the existing system, not because there is a real need. Always start by asking why something is needed and see if you can get that answer using an existing feature easily.
2. Understand the stakeholders
When delivering any sort of software, it is paramount that you spend time understanding who the stakeholders are and what their motivations are. In John Hammond, the park’s creator, we have someone who wants to share a vision with the world. To make people go wow and experience something unlike anything else. In Donald Gennaro, the lawyer, we have someone representing a group of investors who want to know their investment is not going to go down the pan. It is from these positions you can see why they bring in their respective experts — to help them get the outcome they are looking for.
Understanding your stakeholders and what they want out of any solution is key to delivering success. Knowing what they consider to be success will allow you to ensure you can deliver it, but understanding if they are merely representing another party can also allow you to ensure you focus on the right outcome. If you are working with an individual who represents some users make sure those users are happy and feeding that back, then the individual will also be happy.
3. Look for those who might secretly be trying to hinder the delivery
Ah Dennis Nedry. Played wonderfully by Wayne Knight, the lead programmer for Jurassic Park was the one who was sabotaging the whole thing from the inside. Sadly this is all too common when delivering projects — someone is there who doesn’t want things to change.
Keep an eye out for these individuals and try to figure out why they are aiming for failure. It is often just a worry that they are being replaced or will lose some power within the organisation — in which case you can try and bring them onboard to make them more central and end up being an advocate. This is the best and preferred outcome. I will be very honest here though and say it is not always going to be possible, so make sure you know how to deal with these individuals and who to raise their behaviour to if it becomes problematic. And before they shut off the security system.
4. Understand the broader IT landscape
This one builds on the last and can be a helpful way of improving the delivery. No system lives in isolation. All systems are interconnected now and delivering a solution successfully requires you to see how it will be used in conjunction with all the existing system in the organisation.
In Jurassic Park, Lex saves the day in the end by understanding Linux which is running the park’s IT systems. She understood the broader IT landscape and was able to restore the park’s power and ultimately escape. Be like Lex and take an interest in what is running on the broader system’s landscape as it just may save you.
5. Know your points of failure
Let’s be frank, one thing we all wondered in Jurassic Park was why there was a single wire fence and no backup power generator? Once the grid dropped there was only a single fence stopping all manner of beasts escaping and causing havoc. A single point of failure if there ever was one.
It’s important you understand your points of failure and who is responsible for them. When I deliver solutions on top of Salesforce their infrastructure is my point of failure — but this is what I am paying them to manage. When I build a mobile app with a custom backend — the backend is a point of failure that is mine to manage. Know where your points of failure are and how to handle them failing gracefully — and without anyone being eaten.
6. Understand the impacts of your choices
In the film, we are told that they have made all the dinosaurs female to ensure no breeding occurs and that the dinosaur genetic code has been filled out using frogs. We later discover that some of the dinosaurs are male and that the frog DNA has switched sex. This is something some west-African species do when in an environment where all individuals are the same sex and has happened here.
When designing systems we make a number of choices in different areas — database design, architecture, user experience to name a few buckets. All of these choices has an impact on how the system will operate and behave in the long run. I once worked with a client that built a React based component library for all their user experiences, and failed to check whether it would work with a number of their SaaS platforms. It didn’t and they ended up custom building a bunch of things which cost them a lot of time and money, and hindered their ability to change. When we have data come through the system in a certain format, it may hinder our ability to act differently in future or cause errors if someone starts pushing data into the system in a way we did not anticipate.
When making design choices, try to have a view as to what the impacts of these may be further down the line. It’s a balance between pragmatism and flexibility. But if nothing else the exercise is useful and can allow the decision and impacts to be recorded.
7. Know what really needs to be delivered and what is in scope
One of the biggest problems we all face in delivery is trying to do too much. Whether it is an MVP where a couple of extra features get added or a reluctance to be truly iterative which leads to a Big Bang delivery, doing too much in a release happens all the time. And it also happened on Jurassic Park.
Imagine you showed up to the park and there were no carnivores. Firstly, if there was a small explanation notice saying “to a carnivore you would be a tasty treat and so we have decided not to have carnivores for now” you would likely shrug and say “seems sensible”. And then go back to having your mind blown at seeing a live brachiosaurus. You would hardly go “well there is no T-Rex so this sucks”. There is no need for it.
I would also like to note here that the Tyrannosaurus Rex and Velociraptor were both from the Cretaceous and NOT the Jurassic period, so shouldn’t even be in the park! Talk about scope creep! So remember, Know what is actually in scope and stick to that for success.
8. Know how to stop things getting out of control
When something goes wrong in a system, its important to make sure that you stop the entire system from being corrupted and broken. In one of my books I liken systems to nuclear reactions — lots of small controlled reactions are great and provide a tremendous benefit in nuclear energy. If things start to spiral out of control however then you can have a runaway reaction which causes massive damage — a bomb. IT systems are the same, lots of small controlled changes to data are exactly what we want, however, if something starts spiralling out of control you can quickly destroy an entire database and the business associated to it.
When things started to go wrong in the park, they started to go very wrong. Trying to reboot the security system shuts down all the fences and lets the velociraptors — which as discussed should’t even be in the park — out. This just makes everything worse. At this point in the film, only some of the fences were deactivated, and whilst a T-Rex was roaming about, the entire park was not a free for all. Rebooting the system changes this. It is important to know how to handle errors within any system and stop things from spiralling out of control. If something goes wrong, how do we isolate that failure and pump the brakes before things go from bad to worse. Making systems modular and self-contained makes this easier.
9. Have a simple backup and restore plan
Following on from the last point where we want to make sure we can stop things from spiralling out of control, we also need to ensure we have a simple backup and restore plan.
Why was there no backup generator for the fences? Why was it a single generator (a single point of failure — see #5) powering the fences for all the killer creatures? Where was the backup generator? To restore power to a single system (or restore the security system) why did Richard Arnold (Samuel L Jackson) have to reboot everything rather than simply restarting a single portion of the system?
Make sure you have a simple and effective backup and restore plan. Both in terms of data but also for services. What happens if a service goes down? How do we restart an individual service or function? How do we restore our data? Make this simple and one-click where possible and you will avoid being eaten alive when something goes wrong (by dinosaurs, stakeholders or users).
10. Watch out for dinosaurs
Yes it has taken me until point 10 to remind you that you should avoid dinosaurs as they will eat you alive. Well the non-Jurassic period carnivores in the park anyway.
In terms of software delivery I want to be careful with this analogy here. By dinosaurs I want to mean only those who don’t want anything to change ever regardless of the tangible benefit. Its always worked this way, why improve it. They can readily turn into individuals that are trying to derail your work. More often than not, this resistance is founded based upon some real concerns — either for compliance, security or to ensure that a core service is fulfilled still. These concerns can also be around the loss of a job or other Human Resources related worries. Don’t ignore them, ensure that there is a solid change team and process in place to handle this. Often to survive these dinosaurs will need to evolve, but they can also view your delivery as a giant meteor coming to wipe them out…
In conclusion
Hopefully this has given you a smile as well as some ideas. As I mentioned, it came from me sitting and thinking about Jurassic Park as a film and all the things that went wrong. In delivering software many things can derail our delivery, but being mindful of them can help ensure our launch is successful and we all make it out alive.