I was reading Martin Fowler’s blog, and suddenly, a relatively old entry caught my attention: the article Is High Quality Software Worth the Cost? triggered an immediate response in my eyes, and my brain promptly answered with no words, definitively, “It always depends.”
However, since I greatly respect Martin’s work, I read the entire article to conclude that more research must be done.
Trying to quantify the quality of any software product is a challenging endeavor that not even Martin or Uncle Bob had done or were doing already.
I know that measuring productivity is hard, but what if we can measure technical debt and find some quantitative metrics to create a valuable ratio to understand the true impact of cost? Ultimately, lines of code are the primary output for any developer and software product.
Looking for some answers, I started searching for the best resource I could use to understand this problem better; several books, articles, and videos later, I realized that the best person dealing with a valid quantitative and scientific approach was Adam Tornhill. His multidimensional expertise in psychology, forensic investigation, scientific data analysis, and software engineering creates a unique perspective on this complex issue.
Since then, I have spent several days researching the concept of technical debt and answered a few questions I had in previous articles. Although I still have many unanswered questions, a few caught my attention after watching this conference.
These questions will be the focus of today’s post.
Adam has found in more than ~300 free popular source code repositories, written by large teams and by different companies, the same data patterns.
All source code change frequency follows the Pareto distribution, which, in simple terms, means that less than 20% of your total code is the one that hides the objective complexity, and the…
Hotspot analysis for the same repositories confirms that “Code Health” is a real issue where there is no implementation of good coding practices like pattern design, clean code, DDD, and first engineering principles.
If such a fact is actual, if we can measure technical debt using git source control files, we could also measure and quantify:
What is not technical debt, and what are the good practices and principles used the most?
For such an endeavor, let’s start digging into the following questions:
- Are software developers, engineers, and architects (for real) using good coding practices?
- What are the most common good practices we (for real) use?
- What are the common mistakes we make?
I’m still trying to find the answers to the below questions, and the primary purpose of this article is to trigger your curiosity and help me with this matter.
Suppose you are interested in this topic like me, to help you save some research time. In that case, I think the best way to find these answers is by reading Adam Tornhill’s books (Software Design X-Rays, Your Code as Crime Scene First and Second Edition ), watching all his videos, and playing with codescene.io code analysis tool.