Avoiding Sticking-Plaster Solutions


Avoiding Sticking-Plaster Solutions

An unnamed engineering professor at Yale once stated that if he had just one hour to solve a problem, he would first spend up to forty minutes trying to define what the actual problem is. While a variation of this quote is often falsely attributed to Albert Einstein, this only lends credit to the brilliance of the professor’s statement. Far too often, developers are quick to accept requirements without giving them a second thought, but what good is it to race to address the wrong problem?

Well aware of this practice, Software Planet Group believe developers should be primarily concerned with targeting the root cause of an issue. But this is a lot more complex than what meets the eye. Step into any organisation with a desire to build a software solution and you will hear a different story from every employee. While the lack of consensus may be daunting to some, in reality, it only takes place because everyone has different needs, and thus problems affecting them in unique ways.

Avoiding Sticking-Plaster Solutions

This is when the temptation arises to address every individual problem — a move which can only be described as a grave mistake. Nevertheless, this does not stop many software companies from doing this for a living!

It is the classic one-way street form of development: client companies come up with a long list of requirements, and developers, whether by sheer ignorance or negligent compliance, accept them without a word and get straight to work. The resulting sticking-plaster solutions may pose some immediate relief, but they simply mask the underlying problem, allowing it to fester and eventually crop up again in unexpected ways.

A much better approach, on the other hand, is to first conduct a thorough examination of the client company. At SPG, we do this in a variety of ways, but communication is always key. By focusing on our customers and asking pertinent questions regarding their businesses, we are able to learn and educate companies about their real issues. This task is always carried out by one of our senior members of staff, who have accumulated vast analytical experience and know exactly what to look for.

As an example, an effective way to discover the root cause of a problem could be to make use of the 5 Whys, a technique made popular by Toyota’s Sakichi Toyoda during the Japanese industrial revolution. By asking why a problem has occurred at least five consecutive times, Toyoda argued, the true culprit behind an issue is eventually revealed.

Just as in the tale of the coloured envelopes, once the real problem has been located, it is not unusual for the solution to not require a single line of code! After all, we work as partners, not time wasters.

By distinguishing superficial symptoms from actual causes, Software Planet Group are able to create real, long-term solutions that effectively heal the gaping wounds within organisations. This may not always seem convenient, but to quote a thought that does in fact stem from Einstein, “in the middle of difficulty lies opportunity.” It is only by facing our true problems that the answer can be made clear. 

Related Stories

Ilustration for 15 Tips for Working with Remote Developers
February 23, 2022

15 Tips for Working with Remote Developers

The Values Principles and Practices of Extreme Programming
May 29, 2019

The Values, Principles and Practices of Extreme Programming

Git as the core of the dev process illustration
November 13, 2020

Git as the Core of the Development Process

How exactly do we manage our source code with Git and how does the Gitflow branching model fit into our customers' version control processes? Read on!