RIP Test: My 3-Step Process for Solving Any Technical Problem

Two very important quotes that comes to mind when I think of technical problem-solving are:

“We cannot solve our problems with the same level of thinking that created them.” — Albert Einstein

“If your only tool is a hammer, then every problem looks like a nail.” — Abraham Maslow

Too often, developers face two types of problems in their day-to-day activities. These are either:

1. Building new features or
2. Resolving bugs/technical debt in existing features (created or not created by us).

Irrespective of the one you seem to be doing more of, since role diversification may tend to skew you towards one direction more frequently than the other, having a high level strategy on how to approach and resolve these issues when they arise puts you in a more than optimal position to save hours of wasted time and effort, manage expectations and end up with more complete solutions.

Having been in such positions several times myself, I came up with a strategy comprised of a three (3) step process to achieving clarity and success when faced with a similar challenge. These you will see further below.

I call this the R.I.P Test strategy (And, yes RIP doesn’t always have to mean ‘Rest In Peace, but if you think it does, then for the next few minutes, assume what we are killing are our bugs/problems :)

As you can tell already, R.I.P. is an acronym whose meaning is actually dependent on the type of problem you intend to solve. So let’s get to it.

R — Research / Reproduce:

The first phase of the process.

“It is better to solve one problem five different ways, than to solve five problems one way.” ― George Pólya

Researching here is the process of learning more about the problem. Digging deeper. Finding possible solutions/alternatives and gathering as much knowledge about the problem as possible. This phase can take as short a time as 5 minutes or as long as days or even months. Depending on what the scope of the problem is. However, the point remains, you can only suggest the best solution to a problem if you have options to select from and understand what is not a solution to the problem.

If you are resolving a bug, then the ‘R’ in this case can mean Reproduce.

Reproducing a bug means being able to consistently and repeatedly demonstrate its occurrence given a set of environmental circumstances. The outcome of this process is the reappearance of the bug or defect in the development environment. When you are able to reproduce the bug, finding a solution, fixing with clarity and testing that solution becomes easier, assumptions are eliminated and your confidence in the solution is strengthened.

In summary, building a new feature? Then start with research. Resolving a bug? Then try reproducing it first.

I — Identify / Investigate

“Fall in Love with the problem, and the solution will become self-evident” — (Myself)

Fully understanding the problem is a prerequisite to identifying the best possible solution.

Identification here means drilling further down the list of possible solutions/alternatives and letting the most suitable solution for the problem reveal itself. It is important to not just understand the problem, but constraints, expectations and weighing the pros/cons of each approach. These are critical to selecting the most fitting solution.

In bug resolution, this phase involves investigating the root cause of the problem. Why did it happen? Digging into the code if necessary, and identifying changes that need to be made.

P — Perform

This is the easy part. The moment you’ve been waiting for.

“The solution often turns out more beautiful than the puzzle.” Richard Dawkins

The clarity and understanding you will have gained going through the first two phases makes the implementation so much worth more.

This phase involves performing the necessary changes you have identified in the previous phase to bring the solution to reality. In bug resolution, this is when you update the code (…breathe Developer, breathe :).

Bringing the outcome of your thinking to reality is a joy for many developers. It gives you that ‘Aha!’ moment whether building a new feature or fixing an old one. Seeing your solution fitting for the initial problem gives you more confidence and experience.

Test

While this is not necessarily part of the 3-step process, I see this as a requirement that doesn’t need to be stated. Always test your solution. Never assume it works. Environmental circumstances change and things break. Writing good automated tests and a pretty solid QA process will drastically reduce the amount of bugs you push out to users. You want to avoid repetitive tasks as much as possible. This is one major cause of developer unhappiness (But that’s for another post, until then… stay happy by all means).

In conclusion, the RIP Test strategy can be applied to most problems we encounter, not just as developers but also in our day-to-day lives. Problem-solving is not always a strictly linear process. You may have to cycle back to an earlier step as needed sometimes.

I hope this has been and will continue to be helpful to you the next time you resolve a bug or implement a new feature. Take care and go be 10x!