How to Solve Engineering Problems with the Scientific Method

On every new software product, feature or project you develop you are bound to come across challenges that don’t have a clear answer at first.

In an effort to resolve them you likely hold some discussions with your team, consult some people who might know the answer and you might even prepare some bullet points or slides. Yet you still can’t get to an answer that works or an answer that everyone agrees on. Worst case scenario, you’ve alienated or angered people in the process.

After working through countless challenges of different shapes and sizes, from the technical to the commercial, to the political, I’ve arrived at a tool for working them through that stems from my scientist parents. 

The approach is to write out the problem you’re facing following the structure and form of a scientific research article. 

This might take anywhere from 15 minutes to several days involving multiple workshops as well as research and experiments.

For those with a science degree, I want to clarify that this article may deviate from best practice in the production of a scientific paper or applying the scientific method. However I’m unashamedly referencing a “scientific paper” and the “scientific method” because of the shift in mindset I’ve observed that these words bring that gain a noticeable improvement in the end result.

Why take this approach?

The benefits of this approach are:

• It forces you to clearly articulate the problem (which is often the hardest part and, once written reveals the solution).
• It means you lay out the data, the facts, the context and the background which puts everyone involved on the same page, reducing the risk of putting people offside.
• It forces you to describe an approach to resolving the problem you are facing.
• It helps document the way the problem was discussed and resolved so you can refer back to it later (often necessary).
• It helps you articulate the assumptions you are making and the risks you will be taking.
• Ultimately it helps you and those around you form a more objective view.

What is the approach? 

You can use the scientific method to solve a software problem you are facing by taking the following steps. The steps focus on working through a document but the document is really just a tool to help you work through a process for solving your problem.

Step 1: Create a document for your problem

Create a document, page (if you’re on a wiki) or heading (if you already have a doc) with a structure that closely follows the way a scientific paper would be structured. You can speed this up by downloading a template we’ve created for you at the bottom of this document.

The table below shows the sections (headings) you will use next to the sections typically found in a scientific paper along with an explanation of what the section is for.

Your Headings	Science’s Headings	Description
Summary	Abstract	Succinctly state the problem, the solution and the reasons why that solution was arrived at. Usually you complete this last.
Introduction: Context	Introduction	Describe the context of the problem. Often this draws upon the product’s goals, organisational goals or broader constraints.
Introduction: Problem	Introduction	Now articulate the problem itself both as succinctly as possible but also using the facts you have available to you at the time, within the context you’ve just established.
Information Review	Literature Review	Review the information – data, documents, etc – available to you. This might be documents produced by others in your organisation, analytics data, transaction data or third-party research you have access to.
Experiment: Methodology	Methodology	Describe the method you will use to resolve the problem if you still haven’t resolved it. Some problems will require further research such as running an experiment or analysing data.
Experiment: Results	Results	State the results that were obtained from your research.
Solution	Conclusion	Detail the solution you’ve arrived at and discuss why other solutions were disqualified.

Step 2: Give Context and State the Problem

After you have your headings in your document the real work begins. 

In this step you need to give some background and context to the problem that you are facing. In giving context, it is often helpful to state or restate the organisational, product or project goals that are most related to your problem. You also want to provide any constraints (e.g. budget, timelines) that relate to your problem. 

Pro tip: If you’re getting stuck here or anywhere else then just write exactly what is in your head. Don’t filter it, be self-conscious about it or worry about whether it is right. Get it down. Then refine. This approach allows for stating things and then explaining why they don’t work. If you’re doing this then you’re winning.

With your context in place, you now need to clearly state your problem. The better your problem statement the faster you’ll find the right solution. So don’t be afraid to spend time here. 

Before you state your problem you may need to outline the ways in which the context gives rise to the problem. This will help link the problem to context which can come in handy when you’re trying to solve the problem. The more objective and factual you are with your goals, constraints and other areas of background the easier the rest of your work is. 

Linking the context and the problem like this will help you better articulate your problem. Sometimes, just by making a clear link the solution has immediately emerged or, often, some solutions are immediately disqualified.

Personal note: For me this is one of the delightful and rewarding ways to solve a problem. Articulating the context and problem so well that certain solutions are logically disqualified…. Magic.

As you work on articulating your problem, write out the discussion points and arguments evolving in your mind. Doing this will help you work through the nature of the problem itself and the considerations that you need to make. It will also provide you with something you can circulate with others for feedback and further discussion. If in doubt, write it out.

If you haven’t had that moment of delight where your problem is solved just by articulating your problem clearly then you will need to keep working.

Step 3: Information Review

Your next step is to review the information that is readily available to you. In science this is reviewing the work of others. In software development land this is reviewing the work of others (like a colleague or third-party researcher) and also reviewing the data that you can easily access (like data from your analytics tools or database).

As you review the data make notes on what you find and why it is or isn’t relevant. 

What you find doesn’t necessarily have to be insightful, it can just be restating facts. This is important because, although it might be something you know, it may be new information for someone else that you need to collaborate with to solve the problem. Part of your job here is to uncover information so that others can more easily help you and your team solve a problem.

At the end of this step you may want to review your background or problem statement. You may be able to disqualify certain solutions or resolve the problem completely.

Step 4: Design and run an experiment

If you have been unable to truly understand the nature of the problem or arrive at a solution by this stage then you may need to design and run an experiment to solve the problem.

Designing and running an experiment is a bit beyond the scope of this article but if you just do these four things you will be on the right track:

• Plan – write this in your Methodology section
  • Write out what you need to prove or disprove (what you want to learn)
  • Write out the process you will take to prove/disprove
• Do it – follow the process you wrote out. Write down what happens in the Results section.

Pro tip: when dealing with a more political problem like getting alignment or change of mind from a stakeholder then you may want to rename this section from ‘Experiment’ to ‘Approach’.  

Step 5: Summarise and/or Repeat

You can now review your problem and your solutions. If you’ve managed to solve them you can summarise in the Summary section. If you haven’t then you will want to summarise where you landed then repeat this process. 

Keep the Summary section itself to 1-2 paragraphs. If someone needs more information then they can keep reading.

A closing collection of tips

Now that you have the substance of it, here are a few minor tips to help you through these steps:

1. Make sure you keep versions and, where-ever possible, keep everything you write in the document somehow. It helps. Even if you add an appendix or notes section to the end. Seeing how you thought previously, how others thought or paths not to follow is quite useful.
2. Practice makes perfect; don’t expect to nail this approach first go. At first it may seem like extra effort. However, over time those that I’ve helped to follow this have found their thinking evolve where they may no longer need the structure or the document and they naturally start to layout arguments in this way.
3. Avoid superlatives, colourful language and exaggeration. Some examples:
   1. Don’t say “it needs to be really fast” state exactly how fast it must be (and define exactly what it is)
   2. Don’t say “we need to support lots of users” state exactly how many users in what time frames.
4. Avoid “recommending” anything (e.g. “I recommend”, “We recommend”, “Company X recommends” or “the usual approach is” or “in my opinion…”). If you’ve done this exercise properly the logic will speak for itself. You won’t need to recommend, express opinion or draw upon some theoretically authoritative figure like “the usual” or “Company X”.
5. Don’t assume prior knowledge. Don’t assume everyone is aware of what you are aware of. Describe things in plain terms from the beginning.
6. Get down to first principles or second order thinking

---