Why This Language or Framework? Decisions You Can Explain Later

A language or framework choice is bigger than a package choice, and it is much harder to undo. A lead asks "why this language?" to see whether you think about hiring, running it at 3 a.m., and the cost of a second pipeline, not only the pleasure of writing it.

This lesson covers the questions to ask, the "boring technology" idea, how to answer when you pick the same stack and when you pick something different, how to handle a team that wants to move to something new, and how to record decisions. Read Lesson 0 first for the answer shape and Lesson 1 for packages.

Everything here is common practice and opinion, not law. Teams differ. Use the ideas, not the exact words, and always use your own true examples.

Words used in this lesson

• A reversible decision is one you can undo cheaply (change a variable name, try a library on one page). A hard-to-reverse decision is one that is expensive to undo (database choice, public API shape, a language for the whole backend). Spend more thinking on the second kind.
• Technical debt is a shortcut that saves time now and costs time later, like a loan with interest.
• A decision record (ADR, Architecture Decision Record) is a short note that says what was decided, why, and what it costs. It helps people who join later.
• A spike is a short, time-limited experiment to learn something ("one afternoon to try this library on a real page"). You throw the code away afterwards if needed.

"Why this language or framework?"

This question is bigger and costs more to get wrong. Most of the time the honest best answer is boring.

The "boring technology" idea. Dan McKinley wrote that a team has only a small number of "innovation tokens" (he suggested about three). Every new, unproven technology spends one. Well-known tools such as PostgreSQL have known failure modes, lots of documentation, many people who know them, and tested tools around them. So spend your tokens only where a new tool gives you a real advantage for the product, and be boring everywhere else. (Some writers disagree with the "tokens" idea and say the real cost is how hard something is to operate, not just how new it is. That is a fair point: think about running it at 3 a.m., not just writing it.)

Questions to answer before you pick a language or framework:

1. What does the problem need? Heavy maths and data work, a quick web API, low-level speed, a small script? Start from the need.
2. What does the team already know? A language the team knows well is "boring" for this team, and that is a good thing. A better language that nobody knows can be slower overall.
3. Can we hire and onboard for it? In a year, can we find people who can work in it? Is learning material easy to find?
4. Is the ecosystem ready? Libraries, tools, hosting, monitoring, testing. Check that the things you need already exist and are maintained.
5. How will we run it? Build, deploy, logs, errors, security updates. A new language also means a new pipeline and new things to learn at 3 a.m.
6. How hard is it to change later? A language for one small, separate service is easy to undo. A language for the core of the product is not.
7. Is it a learning goal or a business goal? It is fine to want to learn something new. Say it, and try it on something small and safe, not on the payment system.

Example answer when you pick the same language as the rest of the stack:

And an honest answer when you really need something different:

Write the decision down

A choice that is hard to undo deserves a short note in the repository, next to the code. Use the decision-record shape: title (the decision, not the problem), status (proposed, accepted, replaced), context (the forces and the pressure), decision ("We will ..."), consequences (what gets easier and what gets harder). Link it from the pull request. When a decision is replaced, mark the old one as replaced and point to the new one.

# Use TypeScript for the new billing serviceStatus: acceptedContext: The team knows TypeScript. We share types with the web app.A Python service would need a second build and deploy pipeline.Decision: We will write the billing service in TypeScript.Consequences: Easier: shared types, one toolchain, any teammate can review.Harder: heavy data work may need a separate worker later.

How big projects decide: a real RFC process

Large open-source projects show what a careful, but not slow, decision process looks like. The Rust project's RFC process is a public example you can read:

• When you need one: for substantial changes (new language features, large additions to the standard library). Refactors, changes users cannot see, and minor additions do not need an RFC. So the process is for big, hard-to-undo changes only.
• Talk first. The README tells you to discuss the idea informally before writing anything.
• Write it down from a template, open a pull request, and let the right sub-team triage it.
• Build agreement in the open. Changes to the text are made with new commits, so the history of the discussion stays visible.
• A final comment period (FCP) gives a last window (ten calendar days, at least five business days) for objections before a decision, and it is announced widely so affected people can respond.
• Who decides: the responsible sub-team. They do not need every participant to agree, but they must clearly write down their reasoning.

You can copy the shape for a small team: discuss, write one page, give people a fixed time to object, decide, record the reason. The lists above also recommend a lightweight version (the Apache "Lightweight RFC Process") and "Design Docs at Google", which I list in Lesson 11 but did not read.

Two classic warnings from the same technical-strategy section: Joel Spolsky's Things You Should Never Do, Part I argues against rewriting a working codebase from scratch, and Will Larson argues that good engineering strategy is boring. Both fit the "boring by default" rule.

Interview questions

Key takeaways

• Start from what the problem needs, then from what the team already knows.
• Think about hiring, the ecosystem, and how you will run it in production, not only writing it.
• Be boring by default. Spend an "innovation token" only where a new tool gives a real product advantage.
• A new language also means a new build, deploy, logging and security-update path.
• For a new tool, run a small, time-limited spike first, and keep it in a separate piece that is easy to undo.
• Do not choose a tool to improve your CV. Say reasons about the product and the team.
• Write hard-to-reverse decisions in a short note: context, decision, consequences (good and bad).
• This is common practice and opinion. Adapt it to your team.

What's next

Next: Estimates, code review and priorities, Lesson 3. Practise: write one decision note for a choice in your current project, with at least one honest bad consequence.