Software Development is About Problem Solving Not Writing Code – Rio IT
GET IN TOUCH
Software Development is About Problem Solving Not Writing Code

Software Development is About Problem Solving Not Writing Code

Posted on

The most innovative of designs are often born out of the necessity of solving problems. But when it comes to understanding and defining the dilemma, you’ll usually have your work cut out, particularly when it comes to software development.

Perfecting the Problem-Solving Skill

Without knowing the precise issue, you cannot begin to fix it, which is why software development has to be about problem analysis, yet many still consider software development to be about writing code.

If writing code were to be at the core of developing software, more often than not, the wrong solution would be delivered. How so? Well, if the root cause of a problem hasn’t been correctly defined to begin with, the wrong solution will be delivered. So, putting emphasis on writing code as opposed to problem-solving will most likely result in the obstacle not being correctly determined.

When solving the issue is not made the priority, things go wrong, and software developers can end up building systems to meet a need that doesn’t exist. Here we explain in more detail…

Problem Analysis is NOT the Same as Problem-Solving

In order to fully grasp the complication, you’ll need to undergo problem analysis, a vital task which MUST take place before any problem-solving occurs, and is not to be confused with problem-solving itself. The proposing of a solution can often take place too early and therefore does not consider the future implications, leading to either an incomplete or unwarranted solution. So, how can you complete effective problem analysis in order to solve your dilemma?

The 5 Step Approach to Problem Analysis

Meeting a requirement or need is the simplest and most common reason behind why most people choose to buy or build software; needs often arise from problems. We’ve put together a list of steps to help you in defining, understanding and solving such software issues.

Step One; Defining the Problem

Without stating the problem, it’s almost impossible to begin to solve it. You’ll find different people within the company have different ideas about what the complication could be, which is why this is the most difficult part of the project, yet also the most critical.

Common, basic business processes can include anything from issuing an invoice to processing an order but companies will invariably have issues that are specific to their particular business, how they operate and how they engage with their customers.

Consider writing the obstacle down, this formally documents it whilst making the issue better known to a larger group. By addressing the problem to a larger group, you will gain multiple perspectives, and let’s face it; different perspectives are ideal when it comes to refining a multifaceted problem.

Step Two; Understanding the Root Cause

Thinking about the dilemma in depth will mean you naturally look for deeper root causes in order to define it, and group discussions will help to aid this. In doing so, you’ll find there are often multiple root causes to the troublesome situation you find yourself within. Ask yourself “what’s the problem behind the problem?” and in finding the answer to this, the following questions can assist:

  1. What’s the main issue?

This reverts back to Step One, where you write the problem down in order to verify it and make it known to a larger group, just ensure that it’s described accurately and wholly.

  1. What are the causes to the problem?

The causes, or the root cause, are the contributing factors that have led to the issue taking place. They are hidden beneath the surface and require some bait i.e. some thought, in order to coax them out. Once the causes are identified, a greater understanding of the complication will be gained.

  1. Who’s aware of the dilemma?

By asking this question, you’re identifying those who may be able to provide additional insight to the issue at hand.

  1. Is fixing it the right thing to do?

It’s easy to assume that the issue you’re looking at needs to be fixed, but there are alternatives. If it’s a report that’s time consuming to compile, do the recipients still need all of the data within it? Do any of them actually look at it? If it’s a cumbersome process, is there a completely different way of tackling it? Just because “that’s the way we’ve always done it” doesn’t mean that it’s the way you need to keep doing it.

Step Three; Identify those Affected

No matter what the issue may be, it will affect a given group of people. Identify those affected as each of these people will have different needs and concerns, which will need to be considered in the solution. These people are known as the ‘stakeholders’ and could include management, the user, or the customer.

Step Four; Define the Scope of the Solution

By defining the scope of the solution, you will form the boundary you’ll need to work within in order to solve the problem. Doing so will prevent you from overstepping the boundaries of what you can reasonably fix.

The solution itself has two perspectives; the internal which focuses on the problem from our perspective, as the IT service and software provider, and the external, which focuses on the outside interactions such as the customers, users or suppliers.

Defining the scope is all about considering the affected areas of these two perspectives and specifying which can be reasonably and effectively addressed.

Step Five; What Are the Solution Constraints?

As with any software conundrum, there will always be barriers to solving them. Such constraints act as inhibitors and can include any of the following;

  • A lack of time to complete the solution
  • A lack of money to finance the solution
  • A lack of technology to give you leverage in solving the problem
  • Political problems which inhibit people from co-operating in solving the issue

Once these barriers are identified, you can begin to tackle them, yet it is common to see only a partial relief of constraints. Often the inhibitors are out of your hands, and you just have to figure out a way to get round them.

Problems Are Often Opportunities in Disguise

We hope this post has given you a new or greater appreciation of analysis before solution, and a greater insight into why software solutions are greatly based on problem analysis rather than writing code. At the end of the day, computer languages, frameworks, and algorithms are tools that you can learn by studying. Solving problems on the other hand is complicated and hard to learn other than through plenty of practice (and possibly use of our 5 helpful steps?) which is why you should select a partner that has this important skill set and this approach.

As the heading says, problems are often opportunities in disguise… whether it be an opportunity to gain a better insight to your business, to supply a better service, to gain new customers or to make more money… that’s up to you to decide.

Every business is different, and the problems you experience are unique to you. Such problems can only be resolved by using specific (bespoke) software solutions as opposed to the compromise one size fits all ‘off the peg, ready-made’ application. For more information on gaining a bespoke software solution to help solve your problem (but firstly gaining an in depth analysis of the problem) contact Rio IT today.