The nicest thing you can say to a project manager or your boss is something like “I am done with my task / project“. Everybody loves people who are getting things done. If you do that consistently you will get rewarded and used as an example for those other slackers who are having a bit more trouble with getting things done. On the other hand people who write beautiful, elegant and maintainable code hardly ever get any recognition for that. Nobody really seems to care about the “internals” as long as the software somehow does what it is supposed to do. In a cultural environment like this technical quality, code maintainability and sustainability in general are easily thrown under the bus. (more…)
Over time software systems tend to develop several negative symptoms: simple changes require a surprisingly big effort to be implemented, changes cause the system to break in unrelated areas, reuse of code in other systems is simply not feasible, the code is hard to read and understand even for the directly involved programmers. One of the main reasons of facing these symptoms is an unintended increase of the overall system coupling.
Except for very small systems the manual control of the overall coupling is a tedious task – a tool-based approach is needed. Sonargraph-Explorer is such a tool and among other things it helps the developer to assess and control coupling and work against its accidental increase. It is the first product built upon the new Sonargraph Next Generation platform supporting Java, C# and C/C++. It offers different visualizations of dependency structures and a powerful scripting engine based on Groovy which allows extending the built-in analysis capabilities.
The following content introduces the needed definitions and terms related to component coupling (one way to express the overall system coupling). It explains how to use Sonargraph Explorer to visualize the corresponding dependencies and determine components contributing significantly to the overall system coupling with a custom script automatically. (more…)
The metaphor of technical debt is gaining more and more traction. Originally Ward Cunningham used the term for the first time in 1992, describing it like this:
“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.”
It is quite interesting to see that many promoters of agile development approaches now consider an ongoing management of technical debt as critical for the development of high-quality and maintainable software. This challenges the idea that development decision should almost exclusively be driven by business value because it is quite hard to assess the value of paying back technical debt or investing time into a solid software architecture. It seems to me that the value of managing technical debt and a solid architectural foundation increases more than linear with project size. If your project is just a couple thousand lines of code and the team is just 2 or 3 people it is relatively easy to add architecture on demand by continuous refactoring. But as soon as we have tens of thousands of code lines, ongoing development of new features and larger teams things become a lot more complicated. In this case the management of technical debt and investments into a solid architectural foundation pay big dividends, as described thoroughly in this research paper.
The problem is how to measure technical debt and focussing on the right kind of technical debt. I will first discuss measuring of technical debt and then delve into the different categories of technical debt and their impact on project outcomes.