This led me down a rabbit hole of trying to understand various approaches, algorithms and data structures that happen to also power modern AI systems (embedding; supervised learning algorithms like k-nearest neighbours, support vector machines, logistic regression, etc.; transformers; etc.).2

While my little sojourn into this territory and my playing around with some of the popular LLMs by no means makes me an expert in any way on the algorithms themselves, I’ve come to a few assessments so far:

1. LLMs are, as I’d initially suspected, ultimately just probabilistic token predictors (i.e. they predict words, symbols, etc.). This may sound obvious to anyone familiar with the space, but I had to verify my intuitions. They’re very impressive token predictors, of course, and it’s quite a marvel that we can get anything useful out of them at all, but token predictors nonetheless.

2. “Garbage in, garbage out” still applies to LLMs. This is probably why LLMs won’t be killing software development any time soon:

   1. There’s so much garbage software out there today and it seems highly unlikely to me that LLMs are only trained on the highest quality software available.

   2. We software developers generally spend our time doing fairly novel things, for which it’s highly unlikely there’s existing training data for solving the exact problem we’re facing. So while I’m sure that breaking down the problem into steps where there is relevant training data might help, humans still need to break down those problems and then put the LLMs’ recommendations together in a sane and manageable way. And it’ll probably stay that way for as long as we need to build novel things.

   3. What about all the proprietary code out there that LLMs will never be able to be trained on? While that code may not be the best quality, it could represent solutions to entire classes of problems that LLMs will never be able to holistically predict.

3. Even if it’s not “garbage in”, and an LLM is only trained on the highest quality software there is, there are so many ways to still get garbage out of an LLM depending on how its parameters are tweaked.

4. LLMs are not alive or intelligent, and never will be.

5. The promise of robotic/computer “agents” (especially ones based on LLMs) eventually being able to cater to your every need is dead on arrival.

6. The security and privacy implications of the push for agents to have deeper and deeper integration in our everyday lives are pretty scary.

I’ll go into a little more depth on how I currently reason about points 4 and 5, and will link to other more knowledgeable folks’ insights on 6.

LLMs are not alive or intelligent

As token predictors, LLMs are certainly not “alive” or “intelligent”, and they never will be. We can argue about technical definitions of “life” and “intelligence” but those arguments usually lead nowhere because we really don’t have good definitions of those terms at this time.

Life and intelligence seem to me to require the ability of an entity to at least sense what would be “better”, but generally also move or act in that direction.3

Even the simplest of biological life can detect and act in the direction of “better”, like how single-celled organisms propel themselves in the direction of food sources and enact behaviours that protect them from harmful substances or environments.

As some of the most complex living organisms of which we currently know, humans have the ability to mentally map out paths of action potentially many steps ahead. In some cases, these paths may initially seem “worse” but ultimately result in “better” circumstances for the person (e.g. deliberately exercising to eventually become healthier, acting frugally to save up and make a big purchase, or invest time and effort into relationships or learning new skills). This ability to act in ways that result in better conditions for the being in the future seems to be what we intuitively associate with “intelligence” (and the more steps out into the future we’re able to plan and successfully execute, the greater the “intelligence”).

Token prediction to articulate multiple steps in solving a problem might look like intelligence, but it really isn’t. It’s the probabilistic output of a machine that’s acting on encodings of language that have been painstakingly articulated by humans over centuries. LLMs have no inherent notion of or ability to act towards “better”.

Even if you do look at their winning predictions (i.e. the ones they output to their users) as having been produced from some pre-encoded notion of “better”, this speaks more to the notions of “better” defined by the people facilitating the training of the underlying models than any notion of “better” that the models themselves hold.

One could argue that the ecosystems surrounding LLMs (the software developers, businesspeople, customers, etc.) can detect and move towards “better”, but the LLMs themselves cannot. This would mean that LLMs could possibly get progressively better over time at predicting the right tokens to be useful by people in the ecosystem, but the moment they stop being useful in the ecosystem we’d stop paying for them and nobody would run them. Or we’d only really use them in specific, niche circumstances where they could reliably predict the right tokens.

The promise of “agents” is DOA

The idea that a robotic/computational “agent” will eventually know and tend to your needs before you do is utter nonsense. Even more so if they leverage token predictors under the hood, as probabilistic failures compound in a multiplicative and potentially exponential ways.4

Even if machines could detect “better”, they certainly would not be able to detect better on your behalf. We humans can’t even detect better on behalf of other humans, which is why even in healthy, long-term relationships and friendships we still need to communicate about what we need and want. We can only really detect “better” on behalf of ourselves, and even then we often struggle. What hubris to think that we could automate a process that we ourselves can’t even understand or execute manually!

If we built machines that could detect “better” for themselves, we would most likely end up with Skynet. Doesn’t seem to me like a risk worth taking, especially in light of all the other problems humanity faces right now.

This doesn’t even begin to cover the security and privacy concerns introduced by modern agents being pushed progressively lower down in the stack to the OS level. As if gaining more “context” by spying on your every move will somehow allow an agent to detect your intentions, needs and ultimately detect “better” on your behalf. This is, in my opinion, probably a combination of magical thinking, enormous stupidity5 when it comes to security, and possibly even a ruse to trick people into allowing themselves to be spied on to an even greater degree than they already are.

Security and privacy implications of “agent” integration

I’ll leave the more detailed discussion of the security and privacy implications of attempting to integrate agents into the OS layer to the vastly more knowledgeable folks at Signal.

What I mean by “being political” is effectively something like, “consciously or unconsciously navigating interpersonal trust/power dynamics”. Any time two or more people interact, there are trust/power dynamics at play in their interactions. With social interaction being critical for building and maintaining good software, software development cannot be free of such political dynamics.

Why does it feel so gross, even immoral, to talk about trust/power dynamics though? Maybe it’s just me, but I’ve always felt that way. How do we deal with those trust/power dynamics in a healthy way when working with others? And how does one think of and navigate such trust/power dynamics in the tech space specifically?

There’s a philosophical paradigm I picked up in my journey that I find quite valuable in helping answer these questions.

The Metaphysics of Quality

This paradigm comes from two of my favourite books: Zen and the Art of Motorcycle Maintenance and its lesser-known sequel Lila, by Robert Pirsig.

From my own reading of it, the central thesis of ZAMM appears to be that what we call “quality” (or “value”) is all that there really is - it’s the only thing that can be considered a noun in the universe. It’s our name for the intuitive sense we have for that which is the driving force behind evolution. It’s not just an attribute of objects or a perception by subjects - it is the force that progressively gives rise to subjects and objects over time.

Pirsig then goes further to develop the beginnings of a “metaphysics of Quality” in Lila, where Quality can be broken down into:

• Dynamic Quality, which Pirsig equates with the Tao from the Tao Te Ching (“The Tao that can be named is not the eternal Tao.”). It is the “bleeding edge” of the here-and-now. By the time you talk about it, it’s already moved on, so nothing can ever be said about it and it can only be experienced by “I” (see Mead’s “I and me”).

• Static Quality, which is all the “stuff” in the universe. It is only ever temporarily stable before collapsing back into dynamic Quality. One can think of static Quality as, for example, ripples in water. Pirsig talks about there being at least four “levels” to the patterning in static Quality:

  • Inorganic patterns, like electromagnetic waves, elementary particles, molecules and ultimately inorganic matter like stars and rocks, water and air.

  • Organic patterns, like cells, tissues and organisms. Between inorganic patterns and organic ones lies the transition between what we call death and life. Organic patterns can only arise from inorganic patterns (one cannot have cells without molecules), so inorganic patterns form a substrate for organic ones.

  • Social patterns, which emerge when organisms interact with one another. Organic patterns form a substrate for social patterns (one cannot have social patterning without organisms). This is where trust and power/influence dynamics come into play, along with all forms of signalling that organic entities perform to each other (i.e. communication).

  • Intellectual patterns, which arise when other patterns are “internalized” by sufficiently complex social + organic organisms. Social + organic patterns form a substrate for intellectual patterns. Concepts and ideas are effectively intellectual patterns.

Morality

Pirsig then goes further to say that we intuitively understand this movement from inorganic through to intellectual patterns as what we call “moral”. Life is more moral than death, so we invented medicine to pursue life. Healthy social dynamics are more moral than unhealthy isolation. Prioritizing the dissemination of good ideas (intellectual patterns) over politics (social patterns) is what we’d consider to be “moral”. Stories throughout human history are full of dramatizations of the undesirable outcomes when we prioritize the “lower” levels over the “higher” ones.

From what I can tell so far in my personal experience, too much of a fixation on lower levels of patterning generally results in an unhealthy life. For instance, if you fixate on taking care of your body at the expense of your personal relationships, you and those around you suffer. Similarly, if you fixate on power and influence at the expense of the adoption/implementation of the best possible ideas, you and those around you also suffer.

Is it true, unique, complete?

Is Pirsig’s framework “true”? In other words, does reality really work like this? I have no idea. It does seem to be a fairly useful lens through which to look at the world though, at least in terms of its explanatory powers.

Is it unique? Most likely not. Pirsig was heavily influenced by both Western and Eastern philosophy in developing his framework. He himself was a student of philosophy before deciding to leave formal academia.

Is it complete? Certainly not - Pirsig himself wrote in Lila about how others would need to expand/refine his framework in future work. It’s also not the only useful lens through which to look at the world, but I find it fairly comprehensive so far due to its simplicity. I also find it helpful to supplement this paradigm with those proposed by others, some of which I may cover in future posts.

How is it useful?

I say it’s a useful lens in that it explains and gives structure to a bunch of things for me, including this feeling I have around why focusing too much attention on politics and power dynamics feels gross, even immoral.

Politics and trust/power dynamics are a lower level of patterning that, just like our bodily dynamics, are a substrate and necessary prerequisite for human social life. But how much attention do they deserve? Just as better bodily health facilitates better social patterning and thinking, so does our social patterning need to be kept healthy in order to help facilitate the “higher” level patterns.

Power and trust

What does it mean to have healthy social dynamics though? Psychologists and sociologists have written volumes on this, and perhaps I’ll try exploring some of their ideas in future posts.

In the meantime, I’ve found it far more useful to think of social dynamics using a lens of trust than power. It places the locus of control back within the sphere of the individual, whereas the notion of power places it outside of the individual on those who must be controlled or influenced - not a healthy situation for anyone involved. Ultimately, adopting an internal locus of control seems to result in a healthier, happier life, so it seems like a better paradigm to adopt.

Trust and software development

How is this relevant to software development? Again, since software development is generally a highly social activity, I find it worth occasionally reflecting on trust dynamics between people with whom I interact.

Especially the question of: how much trust do I give others? Generally, if I’m not dealing with a narcissist, the more I give the more I get in return. I always try to trust that people have good intentions, regardless of outcomes. This ultimately leads to a healthier work/social environment.

Then there’s also the question of: whose idea ends up being implemented? Is it mine because I’m the person in charge, or is it that of the junior engineer who just joined the team because their idea is better than mine? If I have decision-making authority, I try to prioritize the best idea, regardless of from whom it came. This sort of valuing of the best ideas, the best person for the job, etc. seems to generally work well for society when valued as such. Other approaches, like nepotism or cronyism, tend to result in suboptimal outcomes for society.

There’s much more to be said about trust and influence in the work context, especially the relationship between formal and informal influence, but I’ll leave those explorations for future posts.

The flow of ideas

More broadly, this paradigm also has interesting implications for the flow of ideas in society. Applying it, I hypothesize that ideas flow along lines carved out by trust/influence dynamics between people. Healthy lines of trust/influence facilitate the dissemination of good ideas far and wide, whereas unhealthy ones stem that flow. Sometimes healthy lines of trust/influence can also facilitate the dissemination of unhelpful or even harmful ideas, which is ultimately unhealthy for society.

I don’t have any strong recommendations as to how to fix an unhealthy flow of ideas. It’s a hard problem to solve. In recent years many have tried to stem the flow of misinformation, for example, but that still comes from a place of trying to control people as opposed to empower them to distinguish for themselves - a sign, for me, of an external locus of control, and acting from an unhealthy place like that rarely results in healthy outcomes for others.

The best (and healthiest) thing, I believe, that we can do in the face of constant misinformation and disinformation is empower people with the appropriate tools (psychological and technological) to discern for themselves what’s worth paying attention to and what’s worth disseminating to others.

Conclusion

Pirsig’s “metaphysics of Quality”, for me, provides a useful lens through which to look at the world. It shines a light on how being political is part of our human reality, but also that being political is not the end goal, nor should it be our primary fixation - in fact, it’s innately and intuitively immoral to do so. It helps me ask questions that I’ve found to be quite impactful in my life, and in the work context as a software engineer, team lead and engineering manager.

It’s certainly not the only useful lens out there, but it’s one that I personally like to use quite frequently, supplemented by those of others whose paradigms I’ve found to be useful.

We were talking about how it was difficult to understand some of the idiosyncrasies of one of the parts of our system that’s owned by another team — all of whom were on vacation at the time. Fortunately we could wait until they were back from vacation for us to ask them.

It did, however, make me realize that without all these people working together, collaborating and communicating frequently, the software really wouldn’t have the positive impact in the world that it does. Reflecting on it further, I’d go as far as to say that in general, value-producing software is first people, and then the code that they produce.

From tech- to people-centred

This perspective stands in stark contrast to my own perspective when I was much younger. I (foolishly) aimed to build software that would just take care of itself — build it once (perfectly, without bugs, LOL), users would flock to use my software and give me money, and I’d never need to look at it again. Kind of like publishing an award-winning book and then watching the royalties flow into my bank account. It was a misguided perspective that put the machine and the code at the centre of my paradigm as opposed to all the humans who were there in the background the whole time, but whom my paradigm wouldn’t allow me to see. It also vastly overestimated my powers of intuition to really know what users wanted or needed.

Over the years I’ve encountered so many developers who, like me, put technology at the centre of their paradigms — folks who have the “build it and they will come”, or “build it and we’ll worry about users, operations, maintenance, support, etc. later” mentality that I used to have. This post is an encouragement to people with such a paradigm to try to look at their craft from a different perspective.

Software is primarily made of people

When I write of “software” here, I’m referring to running, value-producing software — the kind that people use to make their lives better in some way. This sort of software is so much more than just code:

• For software to exist in the first place, it needs developers.

• For software to run, it needs to run somewhere and someone needs to ensure that it’s working optimally: it needs operators.

• For software to produce value, someone needs to use it, and get value from using it: it needs one or more users. Even software libraries, which aren’t ever run directly, have users: other developers.

• For software to continue to produce value over time, someone needs to adapt it to users’ evolving needs and its environment: it needs maintainers.

• When software fails to provide the value it’s supposed to, users need someone to whom they can reach out and ask for help: it needs support.

The code of the application is just a thin layer of technology facilitating value-producing interactions between all of these people: consumers and cultivators, to put it another way. It’s a crucial part of that set of interactions, of course, but it’s by no means all-encompassing.

Conway’s Law, which is just as relevant in 2025 as it was back in the 1960s when the idea was introduced, illustrates how people-centric just the development process is:

[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

Martin Fowler even speaks of an inverse Conway’s manoeuvre (originally from this article by Jonny LeRoy and Matt Simons), where if you want to change the overall structure of a large software application you first restructure your organization to reflect the desired high-level software structure and let natural communication patterns do the rest.

Implications

One of the biggest implications from this paradigm shift for me was in how I now think about building and running software-based businesses.

When I was younger, I focused exclusively on the technology and assumed that everything else would fall into place. In recent years, however, when thinking about software-based business ideas (ones where there’s a real user need first), I think to myself: what kind of team would I need to make this a reality, and what kind of environment do we need to cultivate for that team to encourage healthy engagement with each other and our users?

There are other implications for this paradigm shift, of course, largely relating to the influence of individual and group psychology on the way that software is built and evolves over time. I hope to write about my experiences and observations along these lines in the coming months.

Given that I’d been working primarily with imperative languages for decades now, I thought I’d challenge myself to learn a functional programming language. Current and past colleagues and friends had spoken highly of Haskell, especially those who value the ideal of “only making valid program states representable in code”, so I thought I’d give it a try and document my experience.

TL;DR: I don’t think I’ll be using Haskell or other pure functional languages for building anything meaningful any time soon. I suspect that, in all the years of using imperative programming languages, my brain’s adapted to that paradigm of human-computer interaction and it’d be far too much effort, for little or uncertain reward, to really become productive in a pure functional paradigm. YMMV though, of course - this is just my personal experience. And, I still don’t fully understand what a monad is.

Setup

Being used to the simple process of installing Go (brew install go) and Rust (via Rustup), I was a little taken aback at the complexity of the Haskell installation process. While it’s not insurmountable, and GHCup seems to help here, it’s still odd to me that one would need to manually select specific versions of all the relevant tools necessary to get started (as though I know what I’m doing at this point, I mean really 😄).

Setting up my coding environment was fairly simple, although this article sent me down a rabbit hole that made me realize I’d been using Neovim on hard mode for years now (I’ve been loving the simplicity of NvChad and configuring it in Lua, especially with the Lua language server’s help). Several hours later, I had a freshly revamped Neovim setup and the Haskell language server installed, and was ready to start coding.

Hello world

Haskell advocates had previously pointed me to Learn You a Haskell (LYAH), so I started learning the basics of the language there, playing around with GHCi - the interactive Haskell CLI. Only after writing my first “Hello world” application manually did I discover the existence of and how to use cabal, and how it would’ve made my life a little easier to initialize and build standalone Haskell applications. Although, I could’ve done with some simple way of adding dependencies via the CLI, because I couldn’t really figure out the .cabal file’s syntax.

It’s really odd to me that all the Haskell tutorials I could find didn’t start by describing the tooling and how to navigate the basics of building a standalone Haskell application. In fact, they seems to focus pretty much all of their attention on the language and its use via GHCi. Compare this to:

• Go’s getting started tutorial

• Rust’s installation instructions (especially the direct link to the cargo instructions)

Building software is so much more than just writing code. There’s also initializing and organizing your project, managing dependencies, configuring your tooling, building and running the application, writing and running tests, configuring CI, refactoring, etc. I have no interest in programming languages that are a dream to code in, but are a pain-in-the-ass to build, test or get working in CI. I want a glimpse of the whole end-to-end development experience up-front so I know what I’m getting myself into and whether it’s worth investing my limited time and energy.

Advent of Code

One of the things I loved about learning Go was that it was fairly easy to understand and to start being productive. In learning any new skill, it seems as though quick wins early on tend to be a natural motivator to continue learning.

Haskell, on the other hand, made me feel as though my brain was continuously straining to reach a shelf that was too high for someone of my stature. By day 2 of the Advent of Code challenges (which took me until about day 10 of AoC to complete), I felt pretty defeated.

From the complex setup process, to feeling like I was flailing when trying to craft an application, to trying to make heads or tails of the cryptic, esoteric warnings and errors generated by the LSP and compiler, it was a painful experience. Perhaps I’ve been spoiled by Go’s simplicity and the Rust compiler’s helpful, human-readable error messages and suggestions.

Don’t get me wrong, when I finally got my solutions to work they were incredibly concise and elegant. I just didn’t enjoy the process of getting there.

Learning curve

In the early stages of learning a new programming language, I’m aware that I’m solving problems at two levels:

1. How do I help the user solve their problem using a computer?

2. How do I translate my mental model of a potential solution to (1) into this specific programming language and toolchain?

It’s the second problem, the “learning curve”, that really tripped me up with Haskell. Interestingly, I had a similar experience with Rust, and this is also one of my biggest criticisms of Rust: for most of the time when I was learning and using the language, it felt like I was trying to solve language problems more than trying to address the user story - especially when I tried to do complex things in Rust’s async world. That’s fun for a while, but it eventually becomes tedious.

The most enjoyable programming languages, I’ve found, are ones that “get out of the way” and allow me to address the user story as quickly as possible. Maybe I’m getting old, or maybe I just get more of a kick out of seeing the user happy than solving programming language problems.

There are certainly people who just “click” with languages like Haskell - I’ve known a few of them personally. Their mental model of the world fascinates me because of how distinct it is to mine. All of them have been people who, to me at least, seem to hold a deep appreciation for the ideals embodied in mathematics and philosophy, and they generally tend to be somewhat disgusted by languages like Go. They also generally tend to be smarter than me, evidenced to me by how quickly they think and their high degree of verbal intelligence.

The language of the machine

I don’t understand that paradigm of mathematical and functional purity though in the context of computers.

It’s not that I’m against mathematics in any way - I did pretty well in math in high school and during my engineering studies, and particularly enjoyed using differential equations and stochastic processes in the realm of telecommunications. I also know that, without that math, computers wouldn’t even exist.

In my paradigm, however, computer chips just don’t work in a functionally pure manner. When you look at the language of a modern CPU (see, for example, the ARMv9 base instruction set), every part of it is an instruction to do something - i.e. an imperative mode of execution.

Maybe I misunderstand what functional programmers are aiming to do, but the functional paradigm seems to me like an attempt to express an ideal of some kind on top of that fundamentally imperative mode of execution. Never mind the fact that computers themselves, elegant as they can be nowadays, are mathematically imperfect machines that are subject to operating ranges, manufacturing tolerances and are replete with all kinds of hidden workarounds at various levels of their architecture so their various makers could meet their deadlines.

The great, and not-so-great

Okay, enough rambling, let’s get to the lists.

There are certainly a few things that I found pretty great about Haskell and its ecosystem:

1. One can express solutions to certain classes of problems very concisely. I do like the look of this elegance. While this elegance is obvious in solutions to the Advent of Code-style problems, I haven’t yet had enough experience with Haskell to know if this translates well to your everyday garden variety problems (e.g. building CRUD applications).

2. Its type system is far more expressive than other languages I’ve used. This is a big one - while I haven’t personally experienced it, I’m starting to see how its type system lends itself to better compile-time correctness, allowing one to eliminate certain classes of bugs at compile time.

3. The existence of Hoogle blew my mind. Who knew one could build a search engine that allowed you to look up packages and function documentation just from a function signature? For example, I used it to find a function to split a string by newlines, where my query was just: String -> [String], or “find me a function that takes a string, and returns a list or array of strings”.

4. The language server is pretty helpful, especially in terms of making your statements more concise.

Things that I think will dissuade me, at least for now, from continuing to learn it or use it in any production system:

1. It’s still a relatively unpopular programming language in 2024. This, to me, indicates that very few companies will actually use it for production code, and it’ll be hard to find developers to build teams, making the sustainability of such solutions questionable.

2. The learning curve just seems too great. My software development paradigm would need to undergo a far more substantial adaptation than I’d initially anticipated, and it’s unclear to me what the benefit would be to incur such pain at this stage of my career. Especially given Haskell’s relatively unpopular status as a programming language.

And finally, a couple of small things that really irk me:

1. The fact that set membership querying and map element lookups are O(log n) as opposed to O(1). Like, why?

2. I still can’t fully wrap my head around what a monad is, even after apparently using it for years now. After reading many definitions, examples and having it explained to me by functional programming advocates, I feel like that understanding is about to dawn on me. It is, however, still very much night time for me when it comes to monads, and category theory more generally. Given the nature of the language, until I understand category theory better, I have this feeling I won’t really be able to wield it effectively.

Some of the things I love about it:

• It’s a fairly simple language, providing a relatively compact toolbox with which you can accomplish a wide variety of things.

• You can get really far by just using the standard library. It’s rare these days that I find myself genuinely needing to import some specific dependency. And anyways, a little copying is better than a little dependency in many cases.

• Applications compile really quickly compared to other programming languages. If they’re built reasonably well, they run really quickly too.

• Go’s dependency management approach of not having a centralized registry in which artifacts are stored, in my mind, potentially offers greater supply chain attack resiliency than other languages where the artifact in their registry need not match any code at any particular commit in a publicly accessible repository.

• Its colorless concurrency model makes it really ergonomic to build concurrent systems.

• The Go team’s conservative approach to backward-compatibility provides a really stable platform on which to build applications that could last a long time. This makes it a good candidate for building “enterprise software”.

• It’s maintained by a pretty large company who seems to have a vested interest in its success. This gives me a degree of peace of mind that applications I build today could possibly still be compiled in 10 years’ time. This strengthens the case for its use in “enterprise software”, since such software can often exceed hundreds of thousands of lines of code and would be very expensive to rewrite.

But what if, in fact, every pragmatic, valuable solution is an imperfect one? A hack, if you will.

An idea’s been brewing in the back of my mind for some time now: what if reality is filled with these sorts of hacks all the way down to the finest levels of detail? For example, what if atoms are “hacks” of a sort, which are “hacked” together into cells, which are “hacked” together into humans, who hack hardware and software solutions together?

At almost every level of detail I can think of examples of how reality has facilitated structures or processes that work well under certain conditions, but fall apart fairly quickly outside of those conditions. When some smaller structures or processes are “stable” enough, others are built on top of them or by composing them. None of these composed structures, however, could be considered “perfect” because outside of their workable conditions they can become a house of cards.

What makes me think there is such a thing as a “perfect” software solution to a given problem in the first place? Maybe the only practical solutions are necessarily imperfect.

Imperfect, but good enough.