Industries
Software decisions that can survive a later review
Most software decisions are made once and paid for every week afterward. A choice of database, platform or vendor sets the work of the people who maintain it for years, long after the meeting that chose it has been forgotten.
The cost arrives after the choice
A team can build a service in a quarter and then run it for a decade. Maintenance, upgrades, on-call hours and the slow work of changing a system that others depend on usually outweigh the cost of writing it. A comparison that prices only the build is comparing the cheapest part of each option.
Two older observations still hold. Melvin Conway noted in 1968 that systems tend to mirror the communication structure of the organizations that design them, so an architecture is also a decision about how teams will talk. Fred Brooks warned in 1975 that adding people to a late software project makes it later, which is worth remembering whenever a plan depends on hiring to catch up.
What counts as evidence in engineering
A benchmark run by a vendor on its own hardware is a claim about that vendor's test, not about your workload. A proof of concept shows that something can work on a good day with its builders watching. Evidence that settles a stack question looks plainer: load tests on your own data shapes, incident history from teams who run the system at a similar scale, and an honest count of the engineers who already know it.
The common mistake is letting familiarity pass for fit. Knowing a database well is a real advantage and deserves a weight, but it is one criterion among several rather than the answer. The opposite mistake is just as frequent: choosing the newer tool because it interests the people who will not be paged when it breaks.
A stack decision in the room
The Decision names the workload, the options and the team that will operate the result. Criteria are weighted to 100 before anything is scored, so operability and exit cost cannot be quietly outvoted by enthusiasm. Each option has its own Champion, and the Challenger presses hardest on the assumption the favorite leans on, often a migration estimate nobody has broken down.
Inspector marks a published benchmark as unverified until it has been reproduced on comparable work. Craftsman asks whether this team, with its current rota, can carry the plan out. Grandfather looks for the part that will be hard to undo, such as a data model the rest of the company will build against. The Verdict states which option leads, what it rests on, and which load test result would change it.
Keeping the reason with the code
In 2011 Michael Nygard proposed short architecture decision records kept beside the code: the context, the decision and its consequences. The practice works because the next engineer can read why a choice was made instead of guessing. A Decision Passport serves the same purpose for larger choices, keeping the rejected options, the evidence status of each claim and the Human Decision together.
Small, reversible choices are better settled without a room. A logging library or a test runner deserves a short spike and a conversation. Bring the decision to Argumont when it touches data others depend on, a contract with a long term, or a platform that will shape hiring.
A queue for a growing product
A team of six handles 40 million events a day and expects 150 million within eighteen months. The options are a managed queue from their cloud host, a self-run streaming platform, or a Postgres table with a polling worker. Weights come first: operating load 30, cost at expected volume 25, exit cost 20, delivery time 15, familiarity 10. The managed queue is quoted at about $2,100 a month at today's volume. The Challenger points out that the streaming platform needs one engineer's sustained attention, a sixth of the team, and the room counts that time as cost. The Verdict favors the managed queue unless a load test at 150 million events shows ordering problems that only the streaming platform solves.
Questions
- Can a Decision Room compare architectures it has never seen run?
- Yes, as long as the record says so. Claims drawn from documentation and public incident reports are marked by what they prove, and anything that depends on your own load stays an assumption until you test it.
- Should build versus buy be one Decision or several?
- Usually one, with at least three options: build, buy, and a thinner path such as buying now and revisiting at the first renewal. Strategist often proposes that third path when the team has written only two.
- Who makes the final call on a platform?
- The engineering leader or team who will own the system. The Verdict is kept as analysis and the Human Decision is recorded separately with its reason, so a later reader can see both.
Further reading
Bring Argumont a Decision worth challenging.
Start with a paid 60 day pilot on your own real Decisions.