Many non-trivial systems end up as a big ball of mud, not because developers are lazy or reckless, but because it is very hard to avoid that outcome without proper tooling. For example, if your architecture rules are spread by word of mouth or some articles in your company wiki, there is no way of knowing if the code actually conforms to any of your architecture rules. If rules are broken, most of the times developers are not aware of that. That will lead to the erosion of architectural boundaries (if they ever existed) and more and more cyclic dependency groups. In the beginning the cyclic groups start small, but they grow like cancer in your codebase. I actually did some research on that by tracking some open source projects over time. That research confirmed my assumption – if you do not address the problem of ever growing cyclic dependency groups things will only get worse over time, in some cases much worse.
Read MoreSpring Modulith & Sonargraph – Better Together
We created Sonargraph with the vision in mind, that it would allow architects to formally specify an enforceable architectural model. Another goal was to provide exceptional dependency visualization capabilities, so that issues could be easily detected not only in a formal way, but also by just looking at a dependency graph. Sonargraph’s architecture DSL (domain specific language) solved the first problem, while our exploration view solved the second one in a very unique and scalable way. The DSL is quite powerful and easy to learn. For an introduction you could read “How to Organize your Code” on this very site.
But obviously we were not the only ones thinking about a way to formally define architectural rules. Spring Modulith turned out to be a very powerful and successful solution to define domain driven architectures for Spring-Boot applications. Spring Modulith follows a pretty simple hands-off approach that allows the checking of architectural boundaries with a minimum configuration approach.
Read MoreDesigning a Metric to Detect Big Balls of Mud
Almost everyone who worked in software development for a while has come in contact with the dreaded big ball of mud (BBoM). If you are not familiar with the term, it describes software systems that have lost their architectural cohesion and suffer from extreme coupling and large cyclic dependency groups. That makes it much harder to do any changes on those systems, because everything is literally connected to everything else. Therefor it requires developers spending almost all their time trying to understand code before they can risk doing changes. And even then, the chance of regression bugs stay pretty high. If a system reaches this state, doing changes becomes so expensive, that rewriting the system from scratch might be cheaper than maintaining the old system. Unfortunately, very often it is not possible to rewrite the system, because the users can’t wait for years for a system replacement. This puts many development organization in a very uncomfortable place.
A big ball of mud visualized by Sonargraph
Read MoreChanges to the Sonargraph Dashboard
The Sonargraph dashboard was designed to give the user a quick overview about several important aspects of software quality. The most important aspects in our opinion are “Architecture” and “Structure”, which are displayed at the top of the dashboard. After some internal discussions we decided that we could improve the metrics in the “Structure” box. Those changes will be rolled out with Sonargraph version 15.2.0, which is expected to be released this week.
Code Cancer is Costing Billions
You probably never heard about “Code Cancer”, but this term would be an adequate description for some key issues most non-trivial software systems are suffering from. Chances are that your own organization is affected by it right now. In this article I will describe what I mean by “Code Cancer” and offer ideas how to mitigate this problem.
Read MoreUsing Sonargraph-Enterprise to Track Key Quality Metrics
Sonargraph-Enterprise is designed to allow stake-holders to track important software quality metrics over time. The idea is that this would enable the early detection of harmful trends so that issues can be fixed while they are still easy to fix. The metrics displayed by Sonargraph-Enterprise can be fully customized by the user. However, in this article I will explain the “default” profile that comes with a set of preselected metrics that cover important aspects of code health and quality.
Read MoreSetting up Sonargraph on your Project
Over the years we implemented many different methods to set up Sonargraph for your project. Some of them are now quite outdated and are only kept in the tool for compatibility reasons. This article is meant to help you with your initial setup and chose the most effective method for your particular circumstances. There is one section for each language supported by Sonargraph.
General Recommendations
Sonargraph maintains a folder for each software system, that contains a description of your project, the locations of source folders (and class folders for Java), your architecture model and all other parts of a Sonargraph quality model. We call this folder the Sonargraph system folder. It only contains text files (mostly XML) and should ideally be placed in the root directory of your VCS (version control system) repository. You also should add this folder to your VCS, since the Sonargraph model will evolve together with your software system. This will allow you to share one Sonargraph model with all the developers working on your project.
Each Sonargraph software system contains at least one module. Modules usually correspond to the modules or sub-projects in your IDE.
How to initially create this folder for your project is the subject of this article. The folder should have the name of your software system and always ends with ‘.sonargraph’.
Read MoreUsing ccspy for C/C++ Project Setup
Analyzing C/C++ projects with Sonargraph is always a bit more difficult due to the huge variety of different compilers and environments. We recently added a new import wizard that should simplify the process.
For a successful analysis of a C/C++ projects Sonargraph must be able to emulate the compiler you are using and also needs to know which source files are part of the project and the compiler options used for each source file, mostly the -I options for include directories and the -D options which influence conditional compilation.
The first part is solved by a so called “compiler definition”. Sonargraph comes with predefined compiler definitions depending on your platform. If your compiler is not among them you can always create a new compiler definition (menu File / New / Configuration). You can also manage your compiler definitions in the Sonargraph preferences. The main job of a compiler definition is to define the location of implicit include directories (for standard headers like stdio.h) and to define all predefined macros of your compiler platform.
Discovering Software Rot
Since I have seen some announcements about talks targeting the German Corona Warn App, I was interested to see, what kind of information I could extract with Sonargraph.
The project is still pretty young, but maybe, there is already some structural erosion happening? (Spoiler: There is!)
This blog post is about the setup of the analysis-pipeline consisting of Sonargraph-Build and Sonargraph-Enterprise that allowed me to analyse 24 versions (1.4.0 to 2.9.0) of the CWA-Server project and investigate metric trends.
The execution is implemented in Java and published as a new repo “Sonargraph-Build Batch“. If anybody is interested in analyzing past versions of a project with Sonargraph, “Sonargraph-Build Batch” can serve as a starting point.
Read MoreNew Features in Sonargraph 12
Sonargraph 12 is out! This release contains a couple of major changes: A reworked Exploration view, a refactored System view (dashboard) with new metrics and visualizations, faster C/C++ parsing and various other improvements.
Read More