Thoughts on Software Architecture #1
Economic balance for test automation and Architectural Decision Records
Welcome to the first issue of my new format on Software Architecture. I migrated all subscribers to this new platform. Hope you enjoy it!
đ Thought of the Week
Economic balance for test automation
I recently listened to a Podcast with Kent Beck (known for TDD). He reported about his experience made at Facebook. In short: No one wanted to know about TDD (Test Driven Development). He was puzzled and tried to find out why this is the case. His story initiated some thoughts which I would like to share with you:
How much effort should we put into automating tests? TDD tells us, to first write a test case and afterwards the functionality. This slows down development initially. On the other hand, it asserts, that functionality is working and that code after refactoring or enrichment, is still working. This speeds up the delivery of new functionality overall, as less manual tests needs to be done and we can go faster into production without the fear of breaking something. Therefore, most companies (and often architects) demand a high automation rate of tests with 80-100% code coverage as they hope to avoid most bugs with that approach. But is this really a good idea?
I believe that automating tests many benefits in general. But I donât think that we need to demand 80-100% test coverage as it can easily get very expensive. Of course it depends on many aspects, e.g., industry.
One major criteria to decide on test automation is the purpose of the written code and the âevolutionary stageâ of the functionality:
Prototyping, learning and exploring: Speed and time-to-market is key. Only a minimum amount of test automation is reasonable to find out if a new functionality is useful. Gathering feedback and using it to improve functionality has highest priority. Obviously, automating test cases slows down the feedback cycle. Things will change often and a lot of work will be wasted.
Enriching and stabilizing: A functionality which got positive feedback should be implemented properly in the next phase. This includes adding automated test cases to make sure, that functionality keeps stable while enriching. This is important, as users are actively using the piece of software and probably have most joy if it is mostly bug free. With more users more things will break, which were not foreseen, e.g., performance. Itâs unlikely that test cases will cover this before the issues appear as we may not know what to test against.
While applying the above model I do not see the need to demand 80-100% code coverage. My feeling is, that it is not meaningful as we do not know in advance what will break when we scale out the solution. Even if the code coverage is 100%, who guarantees, that it is working in production? (Hint: No one, because this is not part of the definition.)
Instead, we could invest into our architecture, e.g., implement better monitoring capabilities to identify issues earlier, or make use of âfeature togglesâ, to quickly turn on and off functionality. I believe with things like these we can increase the overall product quality at a lower cost, compared to heavy test automation.
Obviously, it is not black and white, but a mix, optimized against different criteria. How do you find the right balance? Which criteria are you considering?
đ Tool / Method of the Week
ⶠArchitectural Decision Records (ADR)
I often get asked: âHow should I document architecture (AD) decisions?â AD in the sense of a software design choice, which addresses a functional or non-functional requirement. I have seen many different approaches in the past. Luckily, there is a group of people which shared their practices. Their approach, templates and knowledge around ADR also got attention by ThoughtWorks, which added it to their Technology Radar as method in status âadoptâ.
A template looks like this:
In the context ofÂ
<use case/user story u>
,
facingÂ<concern c>
Â
we decided forÂ<option o>
Â
and neglectedÂ<other options>
,
to achieveÂ<system qualities/desired consequences>
,
acceptingÂ<downside d/undesired consequences>
,
becauseÂ<additional rationale>
.
đ° Top Resources of the Week
ⶠThe Anti-transformation Transformation
It should be so easy â but do we really always understand and use core principles: (1) The Deming Cycle, (2) Systems Thinking, (3) Transaction Costs and small batches, (4) Culture
ⶠOn System Design with GraphQL
Replacing the traditional REST APIs, Graphql claims to reduce the number of trips to the server helping developers building applications that run faster on different devices and consume fewer data.
ⶠOpportunities and Pitfalls of Event-driven Utopia
The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. (Martin Fowler)
ⶠMaybe shadow IT isn't so bad after all, study suggests
Have you already laid out a roadmap on how to prevent realizing the negative impact of innovative solutions?
End-users subscribe to their own cloud accounts, use their own assortment of devices, and often even hire their own outside developers to build mobile apps and localized applications.Â
The icing on the cake comes when the call finally comes from end-users begging IT to help clean up the mess. There is also the sticker shock CFOs experience when they see the monthly bill for a plethora of online services.Â
At the same time shadow IT may not always be a bad thing. It also serves as a force of innovation and productivity as well.Â
đ Project updates
ⶠBecome a Better Software Architect
My book is released and I plan to start working on my next one. Itâs available as ebook on leanpub and paperback on amazon.
ⶠSVG Placeholder â The customizable & colorful placeholder
I always wanted to play around a bit with serverless. Therefore, I created this tiny and beautiful web-service using Firebase Functions to generate colorful SVG placeholder images for websites. Nothing fancy, but enough to learn and explore a new technology.
Wait, what is this?
Thoughts on Software Architecture is a newsletter with thoughts, resources, and commentary to help software engineers and software architects to create better software. Itâs written by Kai Niklas, who is a principal technology consultant, software architect, Ph.D. and author. If you like this newsletter I would be very grateful if you share it with people you like.
Subscribe now and never miss an update.