But, Did You Test The Architecture?

John Connolly
DDD US Times
Published in
4 min readOct 6, 2023
Photo by Christina @ wocintechchat.com on Unsplash

You deployed it on Friday because the teams ran four days behind, and your environment is still waiting to implement continuous anything. You ran the unit tests: Pass. You ran the integration tests: Pass. You ran all the acceptance tests: Pass. It all took too long, but you are safe. So, you think.

Did you run the architectural tests?

Are There Architectural Tests?

Short answer: Yes.

Why Should I Care?

What happens when you don’t test your architecture and work to correct it? Poor design eventually halts programming and then you restart a new development project, and that cycle starts all over — an expensive way to provide long lasting features. Your greatest cost on a typical development team is the cost of trying to shoehorn a new feature into a poor design. In fact, most of the 2.41 trillion dollars lost in software in 2021 in the United States was due to this problem of poor design.

See: https://www.csoonline.com/article/574723/poor-software-quality-can-cost-time-and-money-straightforward-solutions-are-available.html

Just think about the cost. Without testing the architecture, you only know if you have a cost issue when you are prematurely replacing the software. Most applications should last 15–20 years if they are written in modern languages. Unfortunately, most systems are replaced within 5 years. So if you have 2 systems getting replaced every 5 years when they could last 15 then you now have the average replacement cost multiplied times four and that will grow. What does it cost to prevent that; I am guessing about 1–5%. I don’t need an MBA to know what to do.

If you want to avoid this problem, you need to test your architecture.

Ok, How Do I Test This?

The typical executive crew has not been taught that software devolves by human action and that it is detectable. But it is. Architecture has points of failure. They don’t easily show up in plain sight. They show up in nuanced ways. One way they show up is that you now call your system “legacy” about 10–20 years prematurely. Before that happens, you call it a big ball of mud. Before that happens, you have changes that are hard to implement, and people cut corners. There. Stop. Did you test for that?

Architectural change is good if it is adaptive. This is where coupling, cohesion and more come into play. This is where tools like CodeScene from Adam Tornhill give your organization an exceptional advantage. Where almost all the other code analyzers test systems based on tests your staff writes or very basic metrics that are file based. CodeScene runs tests that were developed by industry professionals with principled solution architectural adaptability as the core driver. You need to know when things are going sideways at the point they are going sideways, but you cannot see them without tools and metrics. I am a long-time developer, and I don’t trust myself to write those metrics. You might love your developers, but you should at least validate that they are providing you with adaptive software through sustainable architectural practices. The cost of the mistake on this is astronomical in many cases. Many of the solution improvements to avoid these costs are rooted in DDD and various architectural paradigms.

Wrapping It Up

There are plenty of quality systems thinkers out there that can help you learn how to solve the problems of poor architecture, but if you don’t know that you have problems, you won’t know what to ask. Before you know it, you are spending a ton of revenue replacing a system that should have worked just fine. That revenue could have been used to expand the business, not keep the software running. This is not a singular loss, but also a lost opportunity cost.

If I am a CIO, I go talk with the team Adam Tornhill put together and then get CodeScene operational on core custom logic as it is really the tool leading the pack on Architectural testing. Then, I ensure teams start correcting code quality by design. I would do this, for the bottom-line, but also, because it is in everyone’s best interest who really wants me to succeed to test the architecture as often as I test my features. The economic benefits are considerable for most organizations and the tool is there to make it happen.

So, go make it happen. Time is likely running out on your current systems. I would love to hear your story if you do.

Disclaimer: This is not a paid advertisement. Comments and ideas are my own.

Photo by Aron Visuals on Unsplash

--

--

John Connolly
DDD US Times

Domain-Driven Design Consultant. Passionately helping domain experts, architects and developers understand domain models improving product delivery.