Evidence at a glance
A Complex Project Can Still See Little Immediate Value in Version Control
On October 11, 2026, Simon Willison revisited how Dwarf Fortress creator Tarn Adams’s attitude to version control changed over time. Adams went years without using it, then said in 2023 that he had started. The shift matters to technical leads not because it proves that a complex game finally needed a particular tool, but because it shows that a tool’s usefulness often depends on how work is organized, not just on the size of the codebase.
In 2013, Adams explained that he avoided version control because he disliked putting code into a “black box” and could not see an immediate benefit. In 2016, he was still saying he did not use it, and described the habit as having lasted about 15 years. That figure was his approximate description at the time, not a precise adoption date. It does, however, make clear that this was a sustained way of working rather than a temporary oversight.
From a familiar software-engineering perspective, version control records changes and lets different lines of work be managed separately, so a long-running project like Dwarf Fortress may seem an obvious candidate. Adams’s comments show that technical fit does not mean a developer will immediately feel the benefit. If the primary developer believes they can still keep direct track of code changes, the process around commits and collaboration can feel more tangible than the abstract value of traceability. That is not an endorsement of going without version control. It is a reminder that a tool’s benefits become real when they connect to the work people actually need to do.
The Turning Point Was a Workflow Change, Not a Documented Migration Date
By March 2023, in an interview about the Steam release of Dwarf Fortress, Adams said that he now had to check Discord channels and use version control, making development “a little more involved.” This gives us a clear boundary: he was using version control by the time of the interview. Public accounts do not establish the exact start date or describe how the project moved from its earlier practice. Another interview transcript says he began about “three months earlier,” but its original recording date is unclear, so it cannot be used to calculate a precise month.
The interview also mentions that more people were involved and that Kitfox’s collaboration had become part of the daily process. The available material does not establish that either factor alone caused the adoption of version control, and it would be too strong to present the change as a technical upgrade directly caused by the Steam release. The cautious reading is that Adams’s work now involved more communication and coordination, and version control became part of that broader workflow. The context places the change during a period of expanded collaboration, but does not provide a single, definitive causal story.
That context also helps explain why Adams described the process as “a little more involved” rather than portraying version control as a cost-free improvement. For a solo developer, additional commits or conventions may feel like friction. When more people are involved, the same records and coordination mechanisms can help them manage shared changes. The question is not whether a workflow is simply “
Branches Enable Parallel Work, but They Do Not Solve Integration
Adams described one arrangement that version control could support: creating a branch for a large-map rewrite while continuing to fix the existing version or work on other substantial features. The branch would let a new line of work remain separate for a time from the version still being maintained. It would not perform the rewrite automatically, nor guarantee that the two sets of changes could later be combined easily. It addresses how work can proceed in parallel, not every difficulty that parallel work creates.
That distinction has practical consequences for technical leads. If the existing version must keep receiving fixes and a rewrite cannot wait until all maintenance stops, a branch offers a way to organize the changes. But the longer the lines of work remain separate, the more changes may need to be reconciled. Version control preserves and isolates those changes. It does not decide which edits can coexist or which parts need to be redesigned.
Adams expected the large branch to produce “quite serious” merge conflicts and acknowledged that he had limited experience dealing with them. This is not an account of a branch that was successfully integrated. It is an explicit assessment of the cost he expected to face. A team deciding to branch should also consider who will integrate the work, how conflicts will be handled, and how long the old path needs to remain active. Without those arrangements, a branch postpones conflict rather than managing it.
Do Not Mistake Version Control for a Way to Maintain Two Games
The classic and graphical versions of Dwarf Fortress are not separate codebases. The interview says they share the same underlying grid structure, and that the distinction between them is mainly handled by changing the displayed glyphs. There is therefore no support for explaining version control as a response to the need to maintain two independent sets of game code. The better-supported interpretation is that it gave the developers a way to manage parallel work on a rewrite, fixes to the existing version, and other features.
It is equally important not to infer details about the tooling. Public accounts say only that Adams used version control. They do not name the tool or hosting platform, describe a branching or review policy, or say whether all code and assets were managed together. The evidence is not even enough to call the tool Git. For technical readers, these gaps are not details to fill in from common industry practice. They are limits that should remain visible when assessing the example.
The case supports a narrower, more useful judgment: when a project long managed by a core developer begins to require collaboration, or when maintenance of an existing version must continue alongside a new direction, version control can become a concrete coordination capability rather than an abstract record of changes. Adopting it adds process, and branching adds integration costs. Leads should assess whether their team can handle conflicts, then design tool choice, branch policy, and maintenance timelines separately. Starting to use version control is not the same as having