I want it all, and I want it now. This is not only a Freddie Mercury quote but also, too often, a general plan for our software product. The picture tells more than words, so here it is, the typical product we designed:
\nAnd, well, that’s probably not what our user wanted. They might just want a sharper steak knife, so something more like:
\nI’m also to blame; I’m falling into precisely the same trap too often. Like recently, while working on Strictland, the contract testing library I announced in the previous article.
\nThe idea behind it is to detect message schema drift easily. You write such a test:
\n@Test\nvoid orderPlacedSchema_DoesNotChange() {\n // Strictland specification\n MessageContract.specification(Json.Jackson.defaults())\n .given(new OrderPlaced(orderId, \"Alice\", placedAt))\n .whenSerialized()\n .thenContractIsUnchanged();\n}It serialises the message and stores the payload inside the same git repository as the test. Thanks to that, you can keep it close and detect contract changes during the review by looking at the changed files.
\nInitially, files were kept in the same folder as the test file. That made it accessible, as you don’t need to jump from one folder to another and see related test files. The file was named by message type class name (so in this case it’d be OrderPlaced.approved.text). Simple, but what if someone adds:
All of that is solvable by some conventions, but what if you’re an open-source library creator like me? Then you can’t assume the same type of thinking, level of tidiness or knowledge of your users. You should be the one to take on the pain and make your users’ lives easier. And guess what? That applies not only to open source, but also to other products.
\n“Taking the pain” and “helping users” can be interpreted as an attempt to please everyone, which translates to the mentioned earlier: “I want it all, and I want it now.”
\nThat’s what I tried to do. I decided to add “selectable storage layouts strategies”:
\nAnd ”selectable storage layouts strategies” were not enough for me. I also wanted to add “various grouping strategies” where one could select whether they want to group message snapshots by:
\nIt sounded smart to me, and hell, with GenAI, I wouldn’t even need to fight with it, as my friend Claude would do it for me, right? RIGHT?
\nNow, ”selectable storage layouts strategies” should sound enough as a warning to me and “various grouping strategies” should ring a loud alarm bell. But it didn’t. I planned how to do it and started the implementation.
\nA few iterations later, the permutations of those various strategies started to pile up. Some of them were just hard to do. Some were conflicting. And most of them weren’t even useful.
\nExamples? I decided to make all files follow the unified format:
\n{messageTypeName}.{version}.{variant}.snap.approved.{extension}
And that’s fine, but then what to use as the message type name? Class name? Fine, but what about a flat layout, or grouping by message type name, with multiple messages of the same name?
\nLet’s use the full class path as the name? Fine, but then what if you have a root folder and a nested folder strategy? Would you nest folders by the class path, and then repeat it in the name?
\nOr maybe you’d differentiate the file name format depending on the strategy one chose?
\nOk, but what if the user decides to change the strategy at some point?
\nI decided to run a sanity check I should have done earlier. Better later than too late. The discussion inside my head looked more or less like this:
\nThat sounds like an obvious thing to do, but it requires pausing to find the time to evaluate our assumptions. We shouldn’t always be mad at ourselves for not predicting everything earlier. Some stuff is just hard to predict. Personally, I usually see some steps after I try to implement them. Those are also the steps I explained in the article about the OODA loop. We should:
\nRinse repeat.
\nIf we think about it this way, the time spent considering those various cases is not wasted. It’s similar to the anti-requirements exercise described by Andreas Öhlund and David Boike or Barry O’Reilly’s Residuality Theory. We gather numerous needs and ideas about our product evolution and see what sticks and what remains. Not all ideas will be great; some will be bad, but that doesn’t matter; it gives us food for thought.
\nStill, we can’t forget about the most important part: subtraction.
\nWe need to subtract all the stuff that’s not needed, leaving only the useful residues, the one that solves the main goal.
\nFor my case, I realised that if I chose the single strategy, it would organise my contract into the root test folder like this:
\n📁 src/test/resources/\n 📁 contract-registry/\n 📁 com/acme/orders/OrderPlaced/\n 📄 OrderPlaced.1.default.snap.approved.json\n 📄 OrderPlaced.2.default.snap.approved.json\n 📁 com/acme/orders/OrderInitiated/\n 📄 OrderInitiated.1.AllData.snap.approved.json\n 📄 OrderInitiated.1.OnlyRequired.snap.approved.json\n 📄 OrderInitiated.2.AllData.snap.approved.json\n 📄 OrderInitiated.2.OnlyRequired.snap.approved.json\n 📁 InvoiceIssuedEvent/\n 📄 InvoiceIssuedEvent.1.default.snap.approved.jsonBy nesting by message type and full path and grouping by contract name, I’m not only keeping snapshots but also creating a Contract Registry.
\nSo this subtraction of some features not only gave me focus on the specific scenario but also enabled me to create scenarios that I would actually like to have eventually, for instance:
\nThat led me to conclude the following two rules:
\nThe addition of imaginary features subtracts the actual value.
\nThe subtraction of imaginary features adds the actual value.
\nIt’s also aligned with my motto: Removability over Maintainability.
\nWe’re not wasting time on building too slowly; we’re wasting time on building stuff that doesn’t matter. All those useless features we imagine without evaluating them with people are a wasted opportunity to deliver better for them.
\nNowadays, with LLMs, it’s tempting to rush into implementation and add every feature we can imagine. That’s never free. We’re increasing the cognitive load for our users and also for us; we waste time on stuff that doesn’t matter and are constantly distracted.
\nYet, if we don’t do sanity checks, trying things in a proof-of-concept way can be a big multiplier. If we stop after that and rethink.
\nI’d still advocate doing a sanity check earlier than I did in the described scenario and thinking first, but not all can be forseen like that. So:
\nAnd that’s precisely what I did: I just released Strictrland 0.4.0 and will plan the next steps based on user feedback!
\nCheers!
\nOskar
\np.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.
","excerpt":"I want it all, and I want it now. This is not only a Freddie Mercury quote but also, too often, a general plan for our software product. The…","fields":{"slug":"/addition-by-subtraction-in-software-design/","prefix":"2026-07-06","langKey":"pl"},"frontmatter":{"title":"Addition by subtraction in Software Design","author":"oskar dudycz","category":"Software Architecture","disqusId":null,"useDefaultLangCanonical":true,"cover":{"childImageSharp":{"resize":{"src":"/static/e21f3e6a6f81e7da9dce92657435fa1f/4fe8c/2026-07-06-cover.jpg"}}}}},"authornote":{"id":"295c4649-a20b-5147-9ca5-5cb77fbcfe66","html":"Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.
\nSome time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.
\nMany people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.
\nMany seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?
\nThe end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.
\nI believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.
\nAfter I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?
\nPeople usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).
\nThe truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.
\nTherefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.
\nPolish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.
\nCheers!
\nOskar
"},"site":{"siteMetadata":{"facebook":{"appId":""}}}},"pageContext":{"slug":"/addition-by-subtraction-in-software-design/","lang":"pl","langKey":"pl","prev":{"id":"c7398fbc-647d-528c-9b7f-0081934eeebd","fields":{"slug":"/announcing-strictland-contract-testing/","prefix":"2026-06-15","source":"posts","langKey":"pl"},"frontmatter":{"title":"Announcing Strictland - new contract testing library for message compatibility","category":"Testing"}},"source":"posts"}}, "staticQueryHashes": ["2742854296"]}