Solving software system problems

Some software system problems are difficult to solve due to various reasons, such as conflicting requirements or complex code structures. To ensure a solution achieves the expected outcome, I follow some steps that are inspired by the Six Thinking Hats and Parkinson’s Law.

Edward de Bono developed the Six Thinking Hats as a problem-solving and decision-making method that encourages diverse perspectives. Each “hat” represents a different way of thinking: the White Hat focuses on facts and data, the Red Hat on emotions and intuition, the Black Hat on risks and caution, the Yellow Hat on benefits and optimism, the Green Hat on creativity and new ideas, and the Blue Hat on organization and control of the thinking process. By systematically using each hat, individuals and teams can explore issues more comprehensively, leading to well-rounded and effective decisions.

Cyril Northcote Parkinson formulated Parkinson’s Law, which states that “work expands to fill the time available for its completion.” This means that if a task has a longer deadline than necessary, it will likely take up all that time, even if it could be completed sooner. The law highlights inefficiencies in time management and productivity, often seen in workplaces and bureaucracies. To counteract this, setting shorter, more focused deadlines helps improve efficiency and prevent unnecessary procrastination.

To verify whether a solution achieves the expected outcome, I follow these steps:

1. Set a short deadline (1–2 days).


2. Narrow the scope based on the deadline.


3. Create a Proof of Concept (POC).


4. If the POC meets the expected outcome, list the software requirements based on it.


5. Analyze implementation options.


6. Plan the necessary changes.

For steps 1 and 2, Parkinson’s Law helps me focus on identifying small, high-impact changes within a constrained timeframe.

For step 3, I use the Yellow, Red, and Green Hats to solve the problem in a small scale, even if it compromises quality. However, I keep an eye on the deadline to maintain focus on the goal.

For step 4, I proceed only if the POC meets the target goal. At this stage, I switch to the White, Black, and Blue Hats to list the functional and nonfunctional requirements based on the POC implementation.

For step 5, with the requirements defined, I consider at least two implementation options with their pros and cons. Then I share these with other stakeholders to gather feedback. The items below show some examples of questions that I do this phase:

• Does the change fulfill its objective?


• How can negative side effects be mitigated?


• How can the benefits be measured?


• How can the change remain backward compatible?


• Are the changes importants for the user?

Finally, at step 6, I decide on an implementation option with the team and document the requirements in a ticket in the release tracking system of the software.

Using this approach, I have solved several software problems throughout my career. I hope this methodology proves helpful to others as well.