Choosing technology and dependencies

A new tool is a bill you pay every month it runs; count it before you add it.

Before you read: predict

ExamHall's four engineers already run Postgres, Redis and BullMQ, which take them about 10, 10 and 6 engineer-hours a month to keep running. After a rubric fix, all ~2,400 attempts of an exam must be re-graded, so the team wants a way to replay grading events. The team's estimates for three plans: Kafka, a topic for grading events and a re-grade consumer, 40 hours to build, and Kafka would take about 20 hours a month to run; Table and job, a grading_events table in Postgres and a BullMQ replay job, 200 hours to build; Kafka for everything, the Kafka plan plus moving BullMQ's other jobs onto Kafka and switching BullMQ off, 160 hours to build.

Counting only build hours and running hours (a cost model) over the next 24 months, which plan costs the team the fewest engineer-hours?

The 30-second version

Every technology you run costs work for as long as it runs. Its base cost is paid once, however many jobs use it, though each extra job may add a little; a new technology brings a base of its own. So keep the set of tools small, and spend your few innovation tokens with care.

A new tool is a bill you pay every month it runs; count it before you add it.

How it works

Step 1 of 13

Two sides to every choice. Each technology solves a problem (the benefit) and must be kept running (the maintenance cost).

In the kitchen

each van model needs its own spares shelf, servicing and drivers trained on its machine, every season it runs → a technology's running cost (steps 1, 3)

Analogy: A family firm of ice-cream vans

Every van is the same model with the same soft-serve machine, so one mechanic, one shelf of spares and every driver can fix a blocked nozzle.

At the van firm	In the stack
each van model needs its own spares shelf, servicing and drivers trained on its machine, every season it runs	a technology's running cost (steps 1, 3)
a new seafront round on the model the firm already runs needs no new shelf	a job on a technology you already run (step 2)
the one or two new things the firm can afford to try in a year	innovation tokens (step 6)
the seasonal freezer van bought for one fair, which only its buyer knew how to defrost	a tool added for one feature (step 8)
before buying a different van for the beach car park, the owner lists what the current van would need there	starting from what you run (step 10)
a new van model tried on one round for a season first	proving it small (step 11)

In real terms: before adding a database, queue or package, write down what it will cost to run every month and what the stack you have would need instead, then decide with your team.

Breaks down when: a van wears out and is sold in a few years, while a technology stays until someone plans its removal and needs patches all the while.

Contrasting case: a festival caterer who hires each event's kit and returns it the next day: when someone else runs each tool, many tools are cheap (step 4).

Examples, run for real

4.1 ExamHall EXH-4400: replay without a new tool

EXH-4400: after a rubric fix, ExamHall had to re-grade every attempt of an exam and had no way to replay grading events; an engineer proposed Kafka. MR !4700 first wrote down what the existing stack would need, then compared 24 months.

4.1 MR !4700 written down: idempotent re-grade per attempt and rubric version 80 h · batches of 500 attempts per exam 70 h · a progress row per exam, so a stopped replay resumes 50 h · 200 h to build on Postgres and BullMQ
4.1 EXH-4400 hours by month · table and job: 1: 200, 6: 200, 12: 200, 24: 200 · Kafka (40 h, then 20 a month): 1: 60, 6: 160, 12: 280, 24: 520

The awkward parts cost more to build, once. Kafka is cheaper for the first months, but its running hours never stop (steps 2, 3, 10).

4.2 Five services, five alerting tools

ExamHall launched one service a month. Its rule: if the newest alerting tool raised more than 5 false alarms in its first month, the next service gets a tool nobody has used. The model gives every tool the same curve: 9 false alarms in its first month, 4 in its second, 2 a month after that.

4.2 rule "switch after an awful first month": 5 tools in production after 5 months · false alarms in month 5: 19 (2 + 2 + 2 + 4 + 9)
4.2 one tool kept for all 5 services: 1 tool · false alarms in month 5: 2

Each new tool started its own awful month, and the old ones stayed (steps 7, 12).

Try it

Answer first, then check. Nothing is saved.

Question 1 of 6

A video-streaming service keeps viewing events in a Postgres table it already runs. Each team that replays the events (to retrain recommendations, to recount views) keeps its own replay job on the service's existing job queue, which takes that team about 3 engineer-hours a month. A Kafka log would let each team read from its own position instead: running Kafka would take about 40 hours a month, plus about 1 hour a month for each team reading from it. Count only these monthly hours (a cost model; the one-off work is about the same either way). Today 2 teams replay the events.

What is the smallest number of teams for which the log costs fewer hours a month than the per-team jobs?

Question 2 of 6

A video-streaming service runs two job queues. The old one carries its 40 kinds of transcoding job; a second queue was added last year for its 3 kinds of thumbnail job. Each queue takes about 10 engineer-hours a month to run. Moving the thumbnail jobs onto the old queue would take 30 hours; moving the transcoding jobs onto the new queue would take 200 hours.

Counting only moving hours and running hours (a cost model) over the next 24 months, which plan costs the fewest engineer-hours?

Question 3 of 6

A video-streaming team runs Postgres and needs two new jobs: title search, and "more like this" suggestions. Three stacks, with the team's estimates (a cost model):

stack  for search / for suggestions             build hours   upkeep a month
X      Postgres / Postgres                       200          25 (the hand-made search and similarity code)
Y      a search engine / the same search engine  120          20 (the search engine)
Z      a search engine / a graph database         60          40 (20 + 20)

Which order ranks the stacks from fewest to most engineer-hours over the next 12 months?

Question 4 of 6

In a mock interview you proposed adding Kafka for a video service's viewing events, which 12 consumers now read from a Postgres table. The interviewer follows up: "Your team has never run Kafka. Say a failure mode nobody knows about yet first shows in the third week Kafka carries production traffic, and hits every consumer reading from Kafka that week. How do you bring Kafka in?" Three candidates answered (each runs as a rollout model):

Whose answer holds up best?

Question 5 of 6

A ticketing start-up of five engineers is built around one thing no rival offers, which its founders call "live pricing". For its first year, three proposals each ask to spend one of the company's innovation tokens.

Which proposal should get one?

Question 6 of 6

An MR to a payments ledger adds an npm package to format the dates on monthly statements, in one file. Its description says: "nicer API than what we have".

Which review comment should come first?

Go deeper

Pro tips

Before adding a package, answer "how would I remove it?" If it would be imported all over the codebase, wrap it behind one module now, so taking it out later is a one-file change. When: reviewing an MR that adds a dependency (step 13). Verify (RAN, tips.mjs): three statement modules that import a fixture date package directly, against the same three importing it through one wrapper module.

tip direct imports: 3 files name the package · package removed: 3 of 3 modules fail to load · files to edit to take it out: 3
tip behind one wrapper: 1 file names it (dates.mjs) · package removed: 3 of 3 fail · dates.mjs alone rewritten onto Intl.DateTimeFormat: 3 of 3 load, same output ("1 Oct 2026")

Source

Dan McKinley, "Choose Boring Technology" (the spoken version of his essay; the row's only source): https://boringtechnology.club/ · fetched 2026-10-15 by fetch-sources.mjs. quote-check.mjs finds every passage below verbatim in the saved text. Quoted: "Every choice has a maintenance cost, but we also get the benefit of the technology that we choose." (step 1) · "We can use the same technology that we’ve already paid for …" and "We have to pay for that new tech, too" (step 2; model rule R1) · "The total cost of our operations is all of the maintenance costs we take on from our choices, minus the development velocity and what-have-yous that we get from every choice." (model rule R2) · "Adding the technology is easy, living with it is hard." (step 3) · "And that makes complete sense if each additional technology choice is cheap." and "We should generally pick the smallest set of tech that covers our problem domain, and lets us get the job done." (step 4) · "none of the tools that you pick may be the “right tool” for any given job. But they can still be the right choice for the total set of jobs." (step 5) · "These represent our limited capacity to do something creative, or weird, or hard." and "Early on in a company’s life, we get like maybe three." (step 6) · "When you first start using it, it’s awful. It’s awful because you find all of the problems." (step 7; model rule R3) · "The new thing won’t be better, you just aren’t aware of all of the ways it will be terrible yet." (step 7) · "This is how you awoke one morning, from uneasy dreams probably, and found yourself with nine alerting systems in production." · "New tech typically has more known unknowns, and many more unknown unknowns." (model rule R4) · "The reason it was possible was because we used the shared stack." (step 8) · "Technology has global effects on your company, it isn’t something that should be left to individual engineers." (step 9) · "It’s really worthwhile to actually write down what all of the awkward things you’d have to do are." and "But it can go the other way, too. You can list all of the unnatural acts and conclude that adding a new thing will be worth it." (step 10) · "You should be proving the technology in production with minimal risk, and then gradually gaining confidence in it." and "Your tactic should not be to rewrite your entire application with it in one step." (step 11) · "Your goal shouldn’t be to operate two pieces of technology that are redundant with one another forever." (step 12). Valid as of 2026-10-15.

The talk does not name a package's licence, size or security record; the row's one-liner does. No item keys on them, and step 13 applies the talk's questions to a package.

Checked against the tools and docs as of 2026-10-15.

Predict first