Problem Solving Thinking


When I started university, the first thing I expected the institution to do was to break down any existing mental models and ideas of what I might think I know. This was replaced with the notion that everything is uncertain, and everything carries risk. Throughout my years post-university and building a career, I have learned one additional important fact:  EVERY PROBLEM HAS A SOLUTION. As a developer, we encounter problems that seem impossible at first, however, with experience, we learn that they are only a series of iterations and hard work away from being solved. In my previous blog, I emphasized the KISS principle (Keep it Simple Silly) and I would like to build on it. An additional principle I would like to emphasize in the world of problem-solving is; if you fail to plan, then plan to fail.  

These 3 key aspects, are crucial to have a successful solution to any problem:   

  • Strategy of work  
  • Work process  
  • Quality  

Strategy of Work:  

If you head in without any strategy, you are trying to bake a cake without a recipe. You might have all the ingredients and all the tools, but if you don’t define a way of using them, your chances of success will be limited. When working in a development environment, there are many strategies that exist that we can follow. One of the best-known strategies is the Agile Methodology? Within the Agile methodology, several tasks are defined to be part of a sprint. A sprint can be any period, most commonly 2 weeks. With this, customer expectations can be managed and people responsible for work know what to focus on and do not worry about all the other tasks remaining. After these tasks have been defined, each of them is broken up into smaller pieces and as such, the elephant is eaten bite by bite. All of a sudden, the problem does not seem so impossible.  

This is however only one strategy, and many more exist out there.  

Work Process:  

Each person within the team and responsible for a task needs to have a personal work process they follow. This is how they will approach the solution more efficiently and reliably.  

Very simply put, when presented with a problem, go about defining the problem in this way upon starting:  

1. What is the trigger/process that starts this all? 

  • If it is automation, then this is a crucial step. For example, once a week the CFO logs into the system, pull a report and presents it to the CEO.  

2. What are the input data/sources that I have at my disposal?  

  • Input data may / may not simplify the design. Instead of catering for every possible permutation of input, you might learn there are only a limited number of scenarios you need to cater for. 
  • Example – The CFO needs to report on all billings, revenue and actual vs. budget for the previous week and this is available out of an ERP system.  

3. What resources do I have at my disposal that I can use/reuse?  

  • This can be anything from design patterns, components, perhaps other technologies, external solutions, solutions from other partners.  

4. What is the output that must be produced?  

  • If the output can be manually replicated, then it is clear what the end goal of the solution is. For Example, create a journal manually that needs to be automated and ensure that it validates and posts.  
  • A consideration – A PowerBI report will be a great visualization, but it also needs to be able to export to Excel.  

5. What are the volumes that need to be addressed?  

  • High volumes might define the solution differently. For example, if it is high demand real-time data that is required, a PowerBI solution would not suffice.  
  • For example, as it is for a global company, volumes can be high, but it need not be real-time.  

6. What can be done to improve the lives of those involved in the solution? 

  • We always want to add value to people’s lives. If the CFO didn’t have to log in to a system but have only the relevant information emailed to them automatically, they would save time.    

7. What are possible additional problem areas that might come up?

  • There might be a connectivity issue, or problems with email.  

8. What objects can I get out of this solution that can be reused on other solutions?  

  • Good financial reports, email functionality, recurring functionality.  

9. What is the priority of this solution?  

  • How critical is this solution for the day-to-day life of the people using it? For example, it will negatively impact the CFO’s KPIs if he/she does not produce that report to the CEO every Monday morning.  
  • After these have been defined, it becomes a lot simpler to break the problem up into smaller pieces.  

If you don’t understand the problem, how are you going to provide a solution? This is the most crucial step that can be done. If you don’t understand what your output must look like, how will you build it.  

The following diagram depicts a simple process flow of how to go about building any solution:  


It is very important to ensure that every element of a solution is of the highest quality. If every element is of high quality, then the entire solution will be high quality. In order to ensure quality across your project, every element must be optimized and continuously tracked. Every single query and part needs to be verified that it uses only what it must use.

Testing also forms a big part of the quality output. The better and more frequent testing is, the better the solution will be. When performing testing it is important to use test cases and history in the quality journey. Performance and stress testing must be done.  


The complexity of designing and building any solution becomes greatly reduced if it is understood, broken down, and simplified. If planning is done accordingly, any problem will have a solution and that solution can be delivered within an adequate timeframe. Every little contribution that t every team member makes to the project matters, it all adds up to produce great results!  

Recent Blogs