Table of contents

Introduction

I came across polya’s technique of problem solving around last year when i was in a meeting of a bookclub. Since then it has helped me greatly solving complex problem quicker and effeciently. Working over years what i have reaslised is that, if you don’t have idea or plan of what you are doing or going to do, the project will take even longer and leads you down the path of rabbit holes which delays project progression and delively and ultimately your productivity.

Before we get more into it, let’s learn what Polya’s techniques is ?

What is Polya’s technique

It is a problem solving technique deviced by George Polya which tells us 3 principles that we can use to solve any problems.

Polya’s Principles of Problem Solving

These principles are:

  1. Understand the problem
  2. Devise a plan
  3. Carry out the plan
  4. Look back

How to use Polya’s technique to solve problems.

While the principles are self explainatory, here is how is use it as a DevOps/SRE engineer.

  1. Look at problem from 10,000 feet and understand what needs to be done. What is the end result ? This involves asking yourself. do you understand the problem well ? What is the thing that you need to solve ? Can you paraphrase the problem into your own word ? Can we picture the problem in you head ? Do you have enough information to solve the problem ? (Understand the problem)

  2. Once you ask the above questions to yourself, note down those answer in your mind or in paper. (Understand the problem)

  3. Make a orderly list of things that needs to be done. (Devise a plan)

  4. Break those tasks down into smaller tasks. (Devise a plan)

  5. List downs the sub tasks that needs to be done for each task to the smallest detail.(Devise a plan)

  6. List down the possible use case you can think of. (Devise a plan)

  7. Come up with implementation plan to address each of those sub tasks against those use cases and note them down.(Devise a plan)

  8. Plan to implement each of the sub tasks to the smallest detail eg at code or function or resource level eg: i will create these local variable named X , and use that local variables and iterate through resource block Y, or i will use this interface named database and it will implement functions create, update, and delete. I will then use object of that interface declared and initialised on server module and pass that object as a dependency to the router. )(Devise a plan)

  9. Iterate that design through various test cases and address the shortcoming.(Devise a plan)

  10. Prepare a design doc, validate, get referenced and double checked by peers. (Devise a plan)

  11. Then you implement the plan. Stick with the order of task and subtask that was you devised as part of your plan of action. This involves actually doing the work which can be writing code, setting up systems etc. Since you have everything (almost everything) figured out before hand, implementaion will come naturally hard parts is already figured out. (Carry out the plan)

  12. Once you achieve what the end goal was then look back and ask yourself, how can i do this differently, is this code reusable. and Goal should be to make it maintainable, readable, and scalable. (Look back)

Something that you should keep in mind

While it’s a great technique, if you do not have a guard rails, then it will let you down a bit rabbit hole of over thinking and let you down the path of overengieering a problem which could have been just solved with just a shell script or a simple command.

Hence, we should keep these mind before while trying to solve problem using Polya’s technique:

  1. Setup guardrails on what you are trying to achieve and what you will not worry about now. This will help narrow down problem and your help your brain not to get distracted.

  2. Plan to keep it simple i.e KISS

  3. Have a mind set to avoid scoop creep. Remember what problem are you solving. Do not deviate from your original plan. Once you figure the problem out, you can address those.

  4. Avoid going down the rabbithole of overengineerring. Focus on planning to prototype and solving the actual problem.

  5. Add plan to make code as our source of truth.

Final thoughts

Sometime it’s the culture that is the limitation on solving a problem effectively and not the technology. Using Ploya’s technique will help you solve problem quicker and efficiently but sometime to do this also the culture needs to change.

In such case, do not try to advocate good culture as doing so will make you look like a jackass. Make sure you show them you can talk the talk, but also can walk the walk if need be. You might not know where the other person is coming from and hence telling them do it this way will just throw them off.

Instead of telling people how it should be done, lead them by showing how its done.

Once correct culture has been set, using such techniques will be much easier and eventually make us a better engineer.

Reference

https://math.berkeley.edu/~gmelvin/polya.pdf

https://www.projectmanager.com/blog/5-ways-to-avoid-scope-creep