Jurassic World: Waiting Until Development Is Done To Bring In The Expert

Jurassic World: Waiting Until Development Is Done To Bring In The Expert

(Originally Posted on Feb 26, 2016)
 While I was heading to Europe for the European Testing Conference, I had a chance to catch up on some movie watching. One movie that was on the list was Jurassic World. Ah the tale of woe that continues to be told from people messing with DNA that clearly should have been left to the prehistoric past.

Science is always exciting. Bones are cool, old stuff is cool, finding things are cool, until you realize that people work long hours in the hot sun and often don’t find the cool stuff for years. Treasure maps don’t exist in reality. But I digress. Back to the point of bringing up Jurassic World and why it involves testing.

“Domain Expert.”

You’ve probably heard this term used if you are anywhere near a development process or follow any number of processes that require the development department have domain knowledge or at least context knowledge of what they are trying to develop. Often, when you have people that are paying attention to the changes in the field they work in or are developing software for a field, they become experts by default, or over a period of time, learning as they go. Once you have enough knowledge, people generally regard you as an expert, or at minimum, someone that people can go to with questions and possibly get answers. Why, then, would a developer not ask questions?

The scenario in Jurassic World: Boss asks for new, bigger, scarier dino to be created. The scientist (aka the developer) takes advantage of this and creates a new, bigger, scarier dino and everyone was impressed. Until some factors were not considered and people start to die. The scientist (developer) combined DNA with properties they knew might have consequences, but decided that it wasn’t important to disclose those. The Boss (product manager) didn’t see the results until it was fully developed and then knew enough about what he was seeing to be worried and called in the Expert (tester or domain expert) to evaluate the project and give a report based on what he saw. The project manager (who is pretty much a manager type, but she obviously ran the show while the boss was legging it around the world), was excited the new project was on schedule and fully developed, ready for investors (aka – ready to ship according to the developer). Does this start to sound familiar?

I’m sure those currently working as independent testers might find themselves in situations where they are brought in at the 11th hour to assess a product. I know I’ve been placed in this scenario myself a time or two. When this happens, often testers or domain experts are seen as nay-sayers, or people holding up the development process. When real defects, which are very serious, like security issues, or behavioral issues are found, because development is already so far along, often those issues are not very well addressed unless brought up while the product development is still in progress.

When it was mentioned, by the expert, that the walls were too short and its mental development from infant to adult was not addressed correctly. The manager brushes it off and explains that they’ve taken precautions even while the dinosaur was trying to give them the slip. The expert was left in the awkward situation of trying to help with damage control rather than enjoying his job.

If a fictional world can prove that having experts associated in the beginning of a project could point things out sooner rather than later and avoid catastrophe, then why do people/companies/employers constantly wait until the last minute or exclude experts all together and ship to the public regardless? A factor might be the amount of risk associated with a project. I admit, when risk is involved, and measured, hopefully, there is more oversight for projects that deal with sensitive information or aviation or shipping toxic waste. I think people would be a lot more worried to discover that many of the things that go on around us are done without bringing in experts, or the experts are so rare that taking them from other projects to evaluate a new one or test it is deemed unnecessary because someone evaluated the risk and decided it is acceptable to them or that the impossible couldn’t happen. If you apply it to real life, you can see the impossible does happen – oil spills, lead poisoning via water sources, refineries located in flood plains that, surprise, become flooded, destroying whole towns. Or even Tsunamis taking out nuclear power plants.

Even worse, the expert or tester is brought in and then when they state their concerns those concerns are ignored or not taken seriously. This happened with the Challenger shuttle explosion and it cost seven people their lives.

Humans need oversight. We need to accept it and understand that while the impossible might never happen, planning for it or at least being aware of it is something the domain expert or tester can do. We present the risks and hope people follow through before it’s too late.

Though I have to admit, we might not have a whole genre of disaster movies if people paid attention to possible complications from the beginning.


Most Read Posts

Ready, Tester One? *GO!*

Learning From Failure: The Tricky iOS Environment

Dear Tester: Github Is Your Friend