What Is Fishbone Diagram?

Fishbone or Ishikawa diagrams were created in 1968 by Kaoru Ishikawa who was a Japanese Professor at the University of Tokyo and was famous for his inventions for quality management.

The fishbone diagram is a pictorial representation and categorization of possible known causes to a problem, usually gathered during brainstorming. The fishbone diagram is being used across several software and manufacturing organizations as a simple visualization tool to depict various potential causes to a problem. It provides a structured way to organize and represent data in a meaningful manner.

This technique can be used whenever there are many possible causes to a problem or whenever there is a need to identify causes to a complex problem. One can apply the fishbone diagram method in solving day-to-day problems as well. This technique is mostly conducted in a group with people from different fields of expertise. However, this method can also be used by an individual as a tool to structure one’s thoughts and identify root causes.

What Is Technical Debt?

Learn Agile

Ward Cunningham introduced the concept of technical debt in 1992. He defined it as follows:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

Cunningham used the ‘Technical Debt’ metaphor to emphasize the benefits and limitations of speedy development. The metaphor was well received by both business and technical people as it resonates with financial debt. Like financial debt, technical debt accumulates interest with late repayment.In 2004, Joshua Kerievsky describes ‘design debt’ in his article ‘Refactoring to Patterns” and the associated costs. Then again in 2014, Grady Booch compared evolving cities to evolving software and described how lack of refactoring can lead to technical debt. He stated:

“The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So, it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up.”