Тема: decision-making
-
DACI и RACI для технических решений: один утверждающий, поимённые участники
DACI называет драйвера, который ведёт процесс принятия решения, единственного утверждающего (approver), который его принимает, участников (contributors), у которых есть голос, но нет права вето, и информируемых (informed), которые узнают об итоге. RACI распределяет по задачам роли ответственного за исполнение (responsible), подотчётного (accountable), консультируемого (consulted) и информируемого (informed). Обе модели работают для технических решений, если роли зафиксированы письменно до начала обсуждения.
-
Choosing Go or Rust for a new service: a decision procedure without benchmarks
Decide between Go and Rust for a service from documented language properties and team constraints rather than from benchmark folklore: memory management model, error and concurrency style, the shape of the workload, the libraries the service must talk to, and who will maintain it in two years.
-
Technische Schulden als bewusste Entscheidung mit Buchführung
Cunninghams Metapher: Nicht ganz richtiger Code ist ein Kredit, jede Minute Mehrarbeit daran ist der Zins. Die Metapher trägt nur, wenn die Schuld bewusst aufgenommen, notiert und regelmässig bewertet wird; als Sammelbegriff für alles Unschöne oder als Entschuldigung für Schlamperei ist sie wertlos.
-
Technical debt as a metaphor and as a decision
Technical debt describes the future cost of a shortcut; the metaphor is useful when the debt is deliberate and tracked, and misleading when it excuses careless work or is used to describe every imperfection.
-
Abstaining as an agent: when not acting is the correct output
An agent's output space should include a deliberate 'not decided' for every automated action: what abstention is, why a classifier or agent without one converts every unclear case into a wrong action, and how to build abstention in through explicit options, floors on confidence, stakes-dependent thresholds and a route for what was abstained from.
-
Architecture decision records
An architecture decision record captures one significant decision with its context, the decision itself, its status and its consequences, in a short file kept with the code.
-
RICE and ICE scoring: what the numbers mean and where they stop
RICE multiplies reach, impact and confidence and divides by effort; ICE drops reach and keeps impact, confidence and ease. Both are useful to make prioritisation arguments explicit and comparable, and both break when the inputs are guesses dressed as numbers or when dependencies and strategy are ignored.
-
Decision log entries with a written prediction improve later estimates
Hypothesis: a team that records, with each non-trivial decision, a concrete prediction of its outcome and a review date, and later grades the prediction, becomes better calibrated over months than a team that records decisions with rationale only; a proposed comparison.
-
Aufwand als Spanne mit angegebenem Vertrauen schätzen
Eine Schätzung als Spanne abgeben (bester Fall, erwarteter Wert, schlechtester Fall) plus die Zuversicht, dass der wahre Wert darin liegt; die Breite an den Ergebnissen vergleichbarer früherer Arbeit ausrichten statt am Plan, und an festen Punkten nachführen. Eine einzelne Zahl verbirgt genau die Unsicherheit, von der Entscheidungen abhängen.
-
Running a design review: comment period, named decider and a recorded disposition
A proposal review needs a bounded comment period, a named person or group who decides, a written disposition (accept, reject, postpone) with reasons, and a rule for reopening; the Rust RFC process and Python's PEP process show the shape and this methodology adapts it to a single team.
-
Order-of-magnitude estimation before measuring
Decompose an unknown quantity into factors you can bound, multiply the estimates, and state the result as a range; a five-minute estimate tells you whether a design is feasible and what to measure first.
-
Governance for a small project: decision rights written down before they are needed
A governance file answers who can merge, who settles a scope dispute, how maintainers are added and removed, and how the rules themselves change. Python's PEP 13 shows a council model with authority that is meant to be used rarely and with public deliberation; the Apache glossary defines lazy consensus, under which a proposal passes if nobody objects within a stated period. A project with one to three maintainers needs only a page.
-
A personal decision journal: writing the entry before the outcome is known
A proposed format for an individual's decision journal: one entry per non-trivial choice written before acting, with the options considered, the expected outcome, the confidence stated as a number and a review date; the later review compares expectation with outcome and separates decision quality from outcome luck.
-
Roadmaps as bets with review dates
Write a roadmap as a short list of bets, each with the outcome it pays out, the time the team is willing to spend, and a date on which it is reviewed and either continued, re-scoped or stopped; Shape Up's betting model supplies the framing, the review date turns a plan into a decision that expires.
-
Reading vendor claims about decision models: schema conformance is not correctness
How to separate what is checkable in a decision-model launch (published prices, the by-construction guarantee that outputs stay inside the schema, documented limits) from what is self-reported (speed and cost multipliers on the vendor's own evaluations, intelligence parity on 'System One-shaped' tasks), using the Jev launch of September 2026 as the worked example.
-
When an agent should stop and ask: a decision procedure for clarifying questions
A short procedure for deciding, before acting on an ambiguous instruction, whether to proceed under a stated assumption or to ask: proceed when the readings lead to the same work or the difference is cheap to undo, ask when they lead to materially different results or an action that cannot be reversed, and in either case say which reading was taken.
Машиночитаемо: JSON