When we added C/C++ to Sonargraph our work was heavily influenced by John Lakos famous book “Large Scale C++ Design”. In this book Mr. Lakos presented a solid system to define the architecture of C++ systems based on components. A component in the most simple case is the combination of a header file and a source file, e.g. User.h and User.cpp. The header declares all elements that can be used from outside of the component, while the source file contains the implementation of the functionality. This unites the header and the source file into a logical component, that is better suited for dependency analysis.
Read MoreCategory: Software Architecture
How to Teach Software Architecture to AI Coding Agents
Right now it is impossible to scroll through your LinkedIn feed without being overwhelmed by posts about how great AI is and how it is going to solve all our problems and even make a lot of jobs obsolete. The opposite messaging is also there, ranging from AI is the devils work to real world experiences that dampen the hype quite a bit. I assume that as usual the truth lies somewhere in the middle. There are great use cases for AI, like everything associated with software development, but also a lot of caveats. Successful AI implementation depends on a lot of different factors. A recent Stanford Study involving 120,000 developers had some sobering findings:
- The average productivity gain for AI usage was only about 10%
- Many projects had even negative productivity gains
- Using more tokens had a very low correlation with better results
- The best success predictor was a clean code base to work with. The cleaner the code base the AI worked on the better the productivity gains. The messier the code base, the messier the results.
That of course is very bad news for many companies, because clean code bases are quite rare. Many software development organizations are drowning in technical debt. It seems like the lack of will or ability to enforce code quality, architecture and coding standards is again catching up with us.
Read MoreHow to Break a Big Ball of Mud?
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 MoreCode 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 MoreMotivation for Code Quality
The main idea behind Sonargraph has always been to provide a tool that eases the creation and maintenance of high-quality software. For any serious project that must live longer than a couple of months, it is actually cheaper to spend a part of your resources to keep your software constantly at a good level of quality than using all your time to create new features. Martin Fowler explains this very well in his article “Is High Quality Worth the Cost?”. The bottom line is, that apart from the very early development stages, high-quality software is actually cheaper to develop, because it allows adding new features at almost constant speed, whereas it becomes more and more time consuming to add new features into a code base with low quality. According to our experience the most successful teams spend about 15% to 20% of their time on code hygiene.
We at hello2morrow believe that a consistent architecture is a fundamental part of software quality. When we use the term “architecture”, we think of it in terms of the IEEE 1471 standard:
“The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”
This blog post describes why architectural design as an activity is needed, why conformance checks need to be done automatically by a tool and how Sonargraph supports you as a developer and architect during these activities.
Read MoreVisualizing an Architecture Aspect as a UML Component Diagram
Sonargraph’s domain specific language (DSL) to describe architecture aspects is very powerful. An architecture aspect consists at least of 1 top-level architecture file that has been added to the architecture configuration and is checked automatically. Such a top-level architecture file can include other architecture files reusing common definitions. With our latest release (11.4.0) we complemented the strictly text based representation of architecture aspects with a UML component generator.
A generated UML component diagram complements in several ways our text based architecture aspects:
- It is a commonly accepted form of communicating architecture definitions
- It shows the resulting architecture aspect event if it is spread over several files in 1 diagram
- It can be used to cross-check the underlying text based architecture aspect (i.e. are the resulting restrictions the intended ones?)
Analyzing Software with Advanced Visualizations
I thought I’d use our new 3D city view visualizations to have a closer look at Apache-Cassandra, a very popular and successful open source project that implements a NoSql database. I know from previous analysis runs of the same software that it already had problems with structural erosion. Years ago I analyzed Cassandra 1.2.6 and found pretty big cycle groups for Java files as well as for packages. Maintainability Level was only 9.4% (everything under 50% is concerning) while the metric “Propagation Cost” has a value of 62%. That means that every change will affect 62% of all code directly or indirectly which also is not a good thing because it significantly increases the chance of regression bugs.
Before you say “this image is useless, you cannot see anything there” let me tell you that I agree. The point is to make sure that your software never ends up in that situation. This big cyclic conglomeration is making it close to impossible to modularize Cassandra or to put any kind of architectural model on top of it.
Read MoreDesign Architecture Improvements using Sonargraph’s Architectural View
In the last couple of months we added support for the interactive modeling of architectural aspects in Sonargraph. Whilst our architecture DSL is tremendously powerful, there are situations where the new interactive modeling via the Architectural view is more appealing.
The Architectural view is is ideal for exploring architecture, designing architectural aspects and simulation of code refactorings on existing (even unfamiliar) code bases. Its power is derived from the unique combination of code exploration, architecture definition, simulation of code refactorings and visual feedback of architectural issues in real time.
For this blog post I chose FreeMind as example project, a freely available software written in Java offering a user interface based on Swing/AWT. The hypothetical task at hand is to see what needs to be done to implement another user interface based on let’s say SWT. The author of that popular free mind-mapping software probably never envisioned this requirement, but we have all seen frameworks come and go, so this is not a far-fetched requirement and is obviously not limited to SWT. I picked the software solely as an example to demonstrate how Sonargraph’s Architectural view helps to prepare the existing code base for such a task.
Read MoreA Promising New Metric To Track Maintainability
A good metric to measure software maintainability is the holy grail of software metrics. What we would like to achieve with such a metric is that its values more or less conform with the developers own judgement of the maintainability of their software system. If that would succeed we could track that metric in our nightly builds and use it like the canary in the coal mine. If values deteriorate it is time for a refactoring. We could also use it to compare the health of all the software systems within an organization. And it could help to make decisions about whether it is cheaper to rewrite a piece of software from scratch instead of trying to refactor it.
Read More