Every engineering organization has one: a Slack thread from three years ago where someone pasted a link to a new build tool, someone else said "this looks faster," and a third person replied with a single-word "+1." That thread became the official decision record for the next half-decade of infrastructure. The reasoning is buried in a scroll of emoji reactions and half-remembered benchmarks. The outcome is a build system that every new hire inherits without context, and that the team will defend or resent for reasons no one can quite articulate.

Build systems and the tooling around them — package managers, CI pipelines, editor integrations — are the rare pieces of technology that outlive the conversations that chose them. A frontend framework might get replaced every two years. A database can be swapped with enough migration effort. But the build system is the substrate. It is the first thing a developer touches in a fresh checkout, and the last thing they fight when a release goes sideways. The Slack thread that picked it is long gone, archived into the void, but the decision lives on in every slow incremental build and every flaky CI job.

This is a story about two competing technologies, the teams that chose one over the other, and what that choice actually did to their day-to-day work. It is also a story about how the way we make these decisions — in a hurried hallway conversation after a demo, without a written record — shapes the systems we end up living with. The tools themselves matter less than the process that selects them. But the process is almost never the thing we talk about.

The Slack Thread That Decides Your Toolchain

The pattern is so common it feels like a law of software development. A pain point emerges: the current build takes too long, the configuration is unreadable, the plugin ecosystem has stalled. Someone on the team has been experimenting with a newer alternative and posts a link in the general channel. The message includes a benchmark that shows a 40% speedup and a screenshot of a config file that looks almost readable. Within an hour, two senior engineers have weighed in with cautious optimism, a junior developer has asked a clarifying question, and the thread goes quiet.

Three weeks later, a pull request appears that migrates the project to the new tool. It is reviewed by the same two senior engineers, who approve it with minor comments. The migration takes a weekend. The old tool is deprecated in the README. The Slack thread is never referenced again. The decision, for all practical purposes, is done.

What the thread does not contain is any of the reasoning. The benchmark was from a blog post that used a toy project, not the team's actual codebase. The configuration screenshot was from a greenfield setup, not a monorepo with 14 legacy modules. The migration cost — two weekends of fixing edge cases, not one — was never discussed. The thread was a catalyst, not a deliberation. And yet it functioned as the de facto decision record, precisely because nothing else existed.

New hires who join six months later are told "we use this because it's faster," but no one can say faster at what, or compared to what, or at what cost. The institutional memory is a Slack thread that no one can search for because the channel was renamed and the link is dead. The decision is now a fact of the codebase, as immutable as the grammar of the language itself.

The problem is not that the team chose the wrong tool. It is that the choice was made without a record that could be revisited, challenged, or learned from. The thread is a poor substitute for an architecture decision record, but it is the substitute that most teams actually use.

What the Winning Tool Actually Got Right

For the sake of argument, let's call the winning tool "Bazel" and the losing tool "Make." These are real tools with real trade-offs. The team that chose Bazel did not do so because it was objectively better in every dimension. They did so because it solved a pain they actually felt, not a pain they were told to feel.

The first thing Bazel got right was that it attacked the specific bottleneck the team was experiencing. Their old Make-based build was spending 90% of its time on deterministic recompilation of unchanged modules. Bazel's incremental engine skipped that work by hashing inputs and reusing outputs. The speedup was not a marketing claim; it was measurable in the team's own CI logs. Within a week, the median build time dropped from roughly four minutes to under a minute. That is the kind of concrete, observable win that makes a tool stick.

Second, Bazel integrated with the team's existing workflow instead of demanding a new one. It worked with the same package manager, the same test runner, the same editor plugins. The migration was a change of the underlying engine, not a change of daily habits. Developers did not need to learn a new way of expressing their builds; they just watched the progress bar move faster. The friction was low enough that even the most skeptical engineer on the team could not argue with the result.

Third, the documentation matched the actual use cases. Bazel's docs did not lead with a theory of incremental computation. They led with recipes: how to split a monorepo into smaller units, how to cache third-party dependencies, how to debug a stale build. This was documentation written by people who had watched teams struggle, not by people who had only built a demo. The community around it filled the gap where the docs were thin, answering questions on forums and in issue trackers with the kind of patience that only comes from having been stuck yourself.

Finally, the performance gains were not just promised; they were sustained. The team measured build times after the migration and again six months later. The improvements held, even as the codebase grew. Bazel's caching layer had a few sharp edges — stale cache invalidation was a recurring annoyance — but the net effect was a build system that made the team faster every single day. That is what a winning tool does: it earns its keep through routine use, not through a single impressive demo.

What the Losing Tool Got Wrong (and Why It Still Had Fans)

Make, the losing tool, was in many ways the more impressive piece of engineering. Its dependency graph was more precise. Its caching was more granular. Its configuration language was more expressive, allowing teams to model complex build matrices with a clarity that Bazel could not match. In the hands of an expert, Make could produce builds that were not just fast but provably correct, with every edge case accounted for.

That technical superiority was precisely the problem. Make was operationally harder. The expressive configuration language had a learning curve that felt like a second programming language. The concept of "targets" and "prerequisites" was intuitive to the tool's authors but baffling to a frontend developer who just wanted to run the tests. The documentation was thorough but written for an audience of build engineers, not for the average web developer. Every small change required consulting the reference manual.

The configuration overhead outweighed the benefits for most teams. A simple project that took ten lines in Bazel required forty lines in Make, and those forty lines were written in a syntax that looked like a cross between YAML and a functional language. The team spent more time maintaining the build configuration than they saved on build speed. The tool's fans, a small but vocal group, argued that this was a matter of discipline: if you invested the time to learn Make properly, the payoff was enormous. They were right, but only for teams that could afford that investment.

Loyalists valued Make's purity. They saw its complexity as a feature, not a bug. The tool made no compromises, and they respected that. But purity is a poor substitute for practicality when the people using the tool are not the people who designed it. The team that chose Bazel did so because they valued their own time over the elegance of the abstraction. The Make fans could not understand why everyone else did not see it the same way.

Migration costs locked teams into Make even when they wanted to leave. The configuration files were not portable. The custom plugins were written by a developer who had since left the company. The build pipeline had grown organically over three years, and untangling it was a project in itself. The team was stuck with a tool that made them slower, but the cost of switching was higher than the cost of staying. This is the trap that keeps losing tools alive long after they have lost.

The Migration That Should Have Happened but Didn't

The team in question knew they should have migrated. The evidence was clear: builds were slow, the configuration was a mess, and every new hire spent their first week learning Make's quirks instead of shipping code. But knowing something and doing something are different when the cost of doing is measured in weeks of unglamorous work.

The cost of switching exceeded the cost of staying. A full migration to Bazel would require rewriting the configuration, porting the custom plugins, and testing every edge case in the build pipeline. The team estimated it would take two weeks of focused effort, and they had no one to spare. The business was pushing for new features, and the build system was not a feature. It was the thing that made features possible, but it was invisible to everyone outside the engineering team.

Institutional knowledge was tied to the old system. The one person who truly understood Make's configuration had written it two years ago and had since moved to a different team. The remaining engineers had a working knowledge of the tool, but not enough to confidently migrate. They knew that Make did something clever with caching that they did not fully understand, and they were afraid of breaking it. The fear was rational, but it was also paralyzing.

Timezone and team spread made coordination hard. The team was distributed across three time zones, and the migration would require pairing sessions and design reviews that were difficult to schedule. The Slack thread that had chosen Make had been synchronous, but the migration would not be. No single owner had the authority to force the change. The tech lead was enthusiastic but not directive, and the rest of the team had other priorities. The migration was postponed, then postponed again, and then forgotten.

The eventual rewrite came only after a crisis. A particularly large release triggered a build that took over an hour, and the CI queue backed up so badly that the team could not ship for a day. The incident was the catalyst that the rational arguments had not been. The team spent the next month migrating to Bazel, not because they had planned it, but because they had no choice. The crisis was the decision record that the Slack thread should have been.

What Craftsmanship Looks Like in Tooling Decisions

If the Slack thread is the anti-pattern, what does the alternative look like? Craftsmanship in tooling decisions starts with evaluation, not a slide deck. The team should have run a pilot on a real project, not a toy example. They should have measured build times on their own codebase, not on a benchmark from a blog post. A pilot of two weeks would have revealed the configuration overhead and the learning curve before the decision was made.

Write down the decision and the alternatives. An Architecture Decision Record (ADR) is a one-page document that states the context, the decision, and the alternatives that were considered. It does not need to be long. It needs to be honest. The ADR for Bazel should have listed Make as an alternative and explained why it was rejected: the learning curve was too steep, the configuration was too verbose, the operational cost was too high. That record would have been a gift to every future engineer who asked "why do we use this?"

Include the people who will maintain it daily. The senior engineers who write the ADR are not the ones who will debug a broken build at 2 a.m. The junior developer who just joined the team will be. Their perspective on tooling is different, and it is valuable. A tool that is powerful but hard to use is a tax on the people with the least institutional knowledge. The decision should account for that tax.

Plan for a two-year horizon, not a two-week sprint. The team that chose Bazel was thinking about the next release, not the next two years. A better process would have asked: will this tool still be a good choice when the codebase doubles in size? When the team grows by five people? When the CI budget is cut? The answers to those questions are rarely in a Slack thread, but they are the questions that matter.

Measure success with operational metrics, not hype. Build time, CI cost, onboarding time, and developer satisfaction are all measurable. The team should have set a baseline before the migration and a target after. They did not, so they could not say whether the migration had actually made things better. The only metric they had was the vague sense that things felt faster, which is not a metric at all.

The Hidden Cost of the Thread That Chose Wrong

Every build failure traces back to that choice. When a cache invalidation bug in Make caused a stale artifact to be shipped, the team lost a day to debugging. The root cause was not the bug itself; it was the decision to use Make in the first place, made in a Slack thread without a pilot. The bug was inevitable, but the choice was not.

Onboarding time doubles for every abstraction. New developers spend their first weeks learning the build system, not the codebase. The configuration is a maze of custom plugins and undocumented flags. The team's documentation does not cover it because the team does not fully understand it. The new hire is left to reverse-engineer the system, which is a slow and frustrating process. The cost is not just the onboarding time; it is the loss of a developer who might have shipped something valuable in that time.

CI minutes and local build times silently grow. The team does not notice the increase because it happens incrementally. A dependency is added, a module grows, a new plugin is introduced. The build time creeps from four minutes to six, then to eight. No one flags it because no one is measuring it. The build system is a background process, and background processes are easy to ignore until they fail.

Developer frustration becomes a retention risk. The developers who are most frustrated are often the most talented, because they are the ones who can imagine a better way. They spend their energy complaining about the build system instead of building features. Eventually, they leave for a company that uses a tool that respects their time. The turnover is silent, but it is real, and it is a direct consequence of the tooling decision.

The tech debt is invisible but compounds daily. It is not in the codebase; it is in the process. Every developer who spends an hour waiting for a build is paying interest on a decision made in a Slack thread. The interest is not recorded in any ledger, but it is real. The team that chose Bazel avoided this debt. The team that stayed with Make paid it every single day.

Leaving a Better Record Than a Slack Thread

The fix is not to make better decisions in Slack threads. The fix is to make decisions that do not need a Slack thread. An Architecture Decision Record is the most practical tool for this. It is a short document, usually one or two pages, that captures the context, the decision, the alternatives, and the consequences. It is written at the time of the decision, not after the fact. It is stored in the repository, next to the code it affects.

Include the trade-offs, not just the winner. The ADR should say what was lost by choosing Bazel, not just what was gained. Maybe the team gave up the expressive power of Make. Maybe they accepted a less precise cache. The trade-offs are the most valuable part of the record, because they are the part that future readers will need to understand when the decision is revisited.

Link to the original thread for full context. The ADR is a summary, not a replacement for the conversation. The Slack thread, messy as it is, contains the questions that were asked and the answers that were given. Link it in the ADR so that future readers can go deeper if they need to. The link might break eventually, but the ADR will survive, and it will point to the conversation as it existed at the time.

Review it annually against current needs. A decision that was right two years ago may be wrong today. The team should schedule a yearly review of its ADRs, asking whether the assumptions still hold. If the codebase has grown, if the team has changed, if the tool has been deprecated, the ADR should be updated or replaced. The review is a small investment that prevents the slow decay of institutional knowledge.

Make it easy to reverse when the evidence changes. An ADR is not a contract; it is a snapshot. The team should feel free to revisit it, to write a new ADR that supersedes the old one. The goal is not to make perfect decisions. The goal is to make decisions that can be understood and revised. A Slack thread cannot do that. An ADR can.

Consider a real-world example: a mid-sized fintech company adopted Bazel after a lengthy evaluation, but the ADR they wrote was a single paragraph with no mention of the alternatives. Two years later, when the team wanted to migrate to a newer build system, they had no record of why Bazel was chosen in the first place. The new team spent months reverse-engineering the decision, only to discover that the original rationale was based on a benchmark that no longer applied. A proper ADR would have saved them that time.

The next time a build tool appears in a Slack thread, pause. Do not let the conversation be the decision record. Run a pilot, write an ADR, measure the results. The thread will fade, but the decision will outlive it. Make sure it is a decision you can explain to someone who was not in the room.