Complex ideas become easier to comprehend when they can be expressed by way of visual analogy. For example, The Boiling Frog is an oft-used analogy that helps to explain how huge changes can quietly come to pass by way of continuous, gradual change. The Ship of Theseus is another famous thought experiment that has helped generations of thinkers contemplate the limitations of "identity" and "continuity." Both of these visualizations help us understand phenomenon that might otherwise be too unwieldy to fit in our limited working memory.
In this essay, we'll examine how "building a castle" works as a visual analogy to explain why so few teams succeed at implementing software that fends off competitors over the long-term (in most cases, for even 5 years). By exploring the challenges inherent to castle-building, we can understand why unlimited wealth is insufficient to ensure a desirable end product. In fact, this analogy shows how unlimited wealth, to the extent it begets a large team on a rushed schedule, reduces the odds of long-term viability.
linkCastles & software blend form and function
The competing demands of "function" vs "form" seed many of the problems shared by castles and software.
By sheer scope, castles are inherently inspiring to human imagination. But "awe-inspiring" is relative. By the middle ages, there were enough castles strewn about that an ambitious baron had to dream big and hire well to match the aesthetic standard set by their forbearers. A microcosm of this "ascending table stakes" phenomenon recently took place in mobile software. Whereas in 2010 it was impressive for a company to offer any native mobile app, fast-forward 10 years, and now every possible need is serviced by 10+ apps. For an ambitious, new product creator to get noticed, they need to craft a spectacle on par with the best of previous generations. This dynamic forces concessions in functionality, and increases the resources necessary to get a foot in the door.
If the logic of "aesthetic reduces functionality" isn’t intuitive to you, imagine building a castle optimized exclusively for “function.” It would be built from cheap, modular materials, like concrete blocks. No limestone, no spires, no windows — pricey frills, the lot of 'em. It would have electricity and plumbing installed in such a way that they were easily accessible, perhaps by running them along the inner edge of interior walls? It would be a single floor, to avoid all the complexity inherent in creating load-bearing support for upper floors. Would a single floor castle with visible wires and plumbing, but no windows, get built in real life? If not, then apparently aesthetic concerns have pull in what ultimately gets built — to the detriment of maintainability.
Anyone who has implemented a home page, with its swooshes and flourishes aplenty, understands the depth of complexity hidden in aesthetic beauty. Much like the baron, the designer will request flourishes that seem impractical, if not for the drive to erect a spectacle that outshines all past.
linkBigger teams increase coordination costs
In both software and castles, time to completion is predicted by 𝑓(budget, requirements). Ostensibly, an all-time best castle can be built by a generously-funded team on a tight schedule, or by a lesser-funded team with decades of time.
In the real world, architects are rarely afforded decades. Most often, the sponsor of a project makes an itemized calculation of “how many hours should be required to build this?” Then they hire enough people to divide the "hours required" by a big number. Their expectation is that the time needed to complete the project is limited only by the size of the budget.
They're partially right. But anyone who has worked with a team on a complex project understands that the cost of a big team doesn’t grow linearly. Coordination costs between n builders on a large team increase geometrically. Every new builder requires instruction to understand their role within the project, who they will report to, the process to acquire materials, and how often they will report progress. To whatever extent allowed by the manager, each new member will familiarize themselves with the existing conventions of the project. In the short-term, there is little observable benefit to a manager consuming time to enforce consistency. In software, that delayed cost effect is called "tech debt." A recent WSJ article estimated that the pending costs of tech debt are currently more than $1.5 trillion.
linkBigger teams require better review processes
There are several reasons that having a larger team increases the predicted maintenance costs.
First, more builders means conflicting conventions accumulate. If Baron von Builder hires five strong men from the village to install castle heating, he must give them specific instructions lest he end up with a sundry patchwork of rooms being wood-heated, boiler-heated, and coal-heated. Even if the baron specifies that all heating is to be driven by the central boiler system, there could significant variability in how the pipes will be installed. To the extent that byzantine piping or welding amalgams are used, future maintainers must possess increasing expertise to understand and adapt that initial work. If the initial work was buried in a meter of solid concrete, that decisions made by those five strong village men will echo through generations.
Second, the more builders participate in creating a product, the less learning that any individual builder can undergo. Often, in castles and software, specific implementation challenges can’t be anticipated beforehand. Every time that a specialist installs a heating module, they learn lessons that may be applied to improve the adaptability of future installs. If the installer is forced to maintain their work afterward, they become hyper-fluent at predicting which installation details contribute to optimal maintainability. Otherwise, they have little incentive to consider the follow-on implications of their install method.
Third, the larger the team, the greater the attrition. Every time that a builder departs the team, the work required to transfer knowledge about the project begins anew. To the extent that the original builders gained experience building for maintainability, that experience must be regained. Usually by repeating the mistakes that the first generation of builders made. The more often that team members depart, the more that the resulting product becomes a heterogeneous mix of elements that no one on the current team can understand, let alone modify.
The larger the team, the more experienced review is needed to enforce the conventions and consistency so central to adaptability.
linkBad decisions compound
As they age, the adaptability of castles and software projects is governed by the quality of the infrastructure laid by the original team. If the original builders were inexperienced, the cost of their poor decisions comes due upon their departure.
For example, if the first level of the castle was out of level by 1%, the second story and third stories of the castle will be even further from level. Worse, to fix an out-of-alignment problem, it may be necessary to remove the upper floors in order to adjust the base floor. The grander the structure, the greater the possible calamity from under-developed infrastructure.
Even if the original builder made a relatively insignificant mistake in their work, it often lingers well beyond the point where it would have been ROI-positive to fix it. Human nature dictates that, to understand the original mistake, and to pause progress until that mistake can be remedied — tends to be far less satisfying (= higher willpower) than building a new floor, or planting a new garden. Therefore, the current team often must be coerced by management to address the mistakes of past generations, even if those mistakes have cost the current team more time (in workarounds) than it would have taken to remedy the problem.
linkBeyond repair?
To the extent that a castle or application becomes popular, it can become effectively impossible to address its shortcomings.
For example, if people rely on the castle for protection from the cold outdoors, it may never be possible to tear out and reinstall the castle’s heating system. The castle’s owner might just opt to install a second heating system alongside the first one. This entails greater ongoing maintenance costs than a single system, but sometimes it’s the only option.
A recent software example of the “too expensive to fix” pattern was the note taking app, Roam Research. The app rode a surge of 2019 Twitter enthusiasm (and its then-ubiquitous #roamcult tag) to rapidly build out minimally-tested infrastructure. It seemed to make sense to prioritize near-term expansion, given the product’s intensely excited community. As 2020 dawned, the company raised millions from venture capitalists with the intent to clean up its bugs and launch a mobile app. What followed was a few noteworthy spats with customers while its original Founder continually struggled to hire and train engineers that could fix the app’s shortcomings before they quit. Years after the app's meteoric ascent, a partially-functional, webview-based mobile app was finally released. It struggled, and, as of 2024, remains mired with a 2.5 (out of 5) rating on the iOS App Store.
The arc of Roam’s rise and fall were an accelerated recreation of their most famous note-taking ancestor, Evernote. Like Roam, it initially surged in popularity, becoming ubiquitous in the early 2010s, only to find themselves stuck in an infrastructure quagmire after having aggressively expanded the size of their team. As the transition to mobile devices became essential, Evernote was unable to release a satisfying mobile client and was eventually forced to sell in 2023 as a distressed asset. Like a castle built from clay, the compromises made on behalf of “rapid growth” can jeopardize the core viability of the structure.
linkExample castles
Let's move past the general challenges of castle-building and look at a few specific examples where the circumstances of the castles' construction influences its final form.
linkThe new and exciting venture-funded project
A quintessential VC-funded startup is one that gets built by conscripting the best open-market talent and giving them a 3-5 year timeline to get from inception to "MVP complete." With funding equivalent to a 2023 Series B round, a large team of the best free-market castle builders could build an impressive-looking castle. Here is an example castle that reddit claims was built in 5 years:
Château du Plessis-Bourré was built in 5 years from 1468 to 1472 according to reddit. As of 2023, it earns 4.5 stars on 1,000+ Google reviews
More pictures: long inner hallway, aerial view, interior bedroom, interior gathering room.
A fine looking result considering the technology available in 1468! Some properties of a castle built under these constraints:
Bona fide moat and three drawbridges proves the benefit of having enough cash to pick the best possible real estate (software equivalent: a premium domain name)
Built using the finest contemporary materials & technologies. According to its home page, "comfortable, bright and airy, the dwelling has remarkable decorations that herald the First Renaissance, including paintings on the ceiling with esoteric symbolism."
Time constraints offer negligible time for experimentation during construction. The construction planners would need to obsess over any possible hangups or delays before starting construction. It would make most sense to follow a methodology akin to the Waterfall model.
Not extensible. Since the castle occupies all of its island footprint, there are no practical means to extend it to accommodate future needs.
Architects can plan certain rooms to be incredibly novel or interesting, because they have effectively infinite resources to bring forth their dreams
Given the tight five-year timeline, this castle must prioritize risk minimization. Once construction is underway, there would be little-or-no time for experimentation. Even if there were 50% more time, the challenge of coordinating a large team of builders would make it prohibitively difficult to try something that hadn't already been proven viable by past projects.
linkEnterprise Project (high budget, long timeline)
An Enterprise castle is a grandiose statement of its time. It showcases the best materials & techniques of the era in which it was built. The facade of an enterprise castle is stately. The interior is ornate, while complying with every government regulation imposed on its builders. In contrast to the New VC-funded Project, Enterprise Projects are created with the expectation they should remain viable for generations.
Château de Versailles, constructed in many phases from 1631 through 1675 (as it stood in 1668). 4.6 stars on 120,000+ Google Reviews
More pictures: the grounds; one of its grand entrances; aerial view for scale; interior room.
This castle oozes panache. Its creators spared no expense to ensure visitors would leave feeling dazzled. It is a testament to the potential of the human ambition (and the exploitation of its tax payers, but I digress). Some fundamental traits of an Enterprise project like Versailles include:
Unlikely to take shortcuts in creating infrastructure. Important that everything be "up to code" to whatever extent it has been defined for the era
Much easier to "add more" than to "improve/retrofit existing" concepts (ex 1, ex 2), particularly because the individual(s) that built the original are likely to be absent when the v2 work gets underway. Intrinsically, humans find it more satisfying to create new and shiny things of our own tastes than to do the harder work of understanding the previous work well enough to reuse it
Premium location, chosen both for proximity to an existing population source and for its potential to be expanded as generations passed
Built by generations of evolving owners & stakeholders means low consistency between successively built sections
Infrastructure upgrades treated pragmatically; there's usually something more spectacular to work (like fountains) on than improving the sewer or airflow
Upgrading infrastructure is resource-intensive, requiring large-scale coordination between teams
linkBootstrapped Project (low budget, long timeline)
A bootstrapped, or "lifestyle business" castle is one that is constructed by a small handful of people. Since they are operating on limited resources, their construction happens over an extended time period. They creators tend to have a deep personal need for the project, as evidenced by their tendency to work on it for a substantial fraction of their lifespan. A castle like Neuschwanstein is an analog for companies like Honeybadger or GitClear: the founders created it to serve their own needs, and the project tends to occupy their imagination whether they're on the clock or not.
Neuschwanstein Castle was principally driven by a single architect from 1859 through 1886. It was first sketched in a diary, and its construction didn't end until its creator's life did.
More pictures: interior room; one exterior entrance; and a brief history of its planning and execution by King Ludwig II.
A castle like this will never be mistaken for Versailles. There is nary a golden toilet to be found across its broad expanse 😢. In lieu of a gold loo, it differentiates on novelty and efficiency:
Aesthetically a grab bag based on the tastes of founders. Bends toward "antiquated but functional" on long-term horizon
Limited in scale vs. enterprise castle: often planned by a single individual, and implemented by three or less, which limits its size in the short-to-medium-term. In the long-term, it is possible for small teams to accomplish relatively large-scale achievements.
Implements advanced technological features for the time, such as central heating, running water, and an electric bell system for summoning servants
Since builders are maintainers, there is ample incentive to optimize for maintainability
Since the builders will live in it, functional concerns tend to be more salient in the product vs other castle types
Inspiring views showcase attention to daily livability
The greatest advantage conferred by the lifestyle castle is that the planner and builder will "dogfood" the castle, experiencing firsthand its joys and limitations. The difference between a product built by its users, vs. a product built by those who can only imagine how it will be used, is manifest in details like the central heating and running water, which were unusual flourishes for the era of the castle's construction.