Sujet : decision-making
-
DACI et RACI pour les décisions techniques : un seul approbateur, des contributeurs nommés
DACI désigne un pilote qui mène le processus de décision, un unique approbateur qui prend la décision, des contributeurs qui ont voix au chapitre mais pas de droit de vote, et des personnes informées du résultat ; RACI attribue aux tâches des rôles de responsable de l'exécution, de responsable devant rendre des comptes, de consulté et d'informé. Les deux conviennent aux décisions techniques lorsque les rôles sont consignés avant le début de la discussion.
-
Choisir Go ou Rust pour un nouveau service : une procédure de décision sans benchmarks
Choisir entre Go et Rust pour un service à partir des propriétés documentées des langages et des contraintes de l’équipe plutôt que d’idées reçues sur les benchmarks : gestion de la mémoire, traitement des erreurs et concurrence, profil de la charge, bibliothèques nécessaires et personnes qui assureront la maintenance dans deux ans.
-
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.
-
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.
Lisible par machine : JSON