Interesting philosophy is very rarely an examination of the pros and cons of a thesis. Usually it is, implicitly or explicitly, a contest between an entrenched vocabulary which has become a nuisance and a half-formed new vocabulary which vaguely promises great things.

Richard Rorty

I recently came across React.js: The Documentary at the end of a YouTube rabbit hole. It’s a fascinating glimpse into the history of a library that now dominates frontend web development.

What immediately stands out is how contingent the emergence of React was. In hindsight it’s easy to imagine that a web framework backed by Facebook was inevitable. Today, the concepts that it pioneered—the Virtual DOM, JSX, uni-directional data flow, component-based UIs—are so ubiquitous that it’s difficult to imagine a frontend landscape without them. But the story that emerges from the documentary is not one of Big Tech inevitability, but rather a motley crew of young developers overcoming the odds to bring a radical idea to life.

Along the way, if a couple engineers had not gotten on board, or if a Facebook manager had vetoed a months-long React rewrite of their critical ad creation workflow, or if an unproven React had not been brazenly chosen for the post-acquisition development of Instagram’s web platform, the whole thing might just as easily have fizzled out. Even after proving itself in production within Facebook, when React was open-sourced at JSConf in 2013 it was received by the frontend community not with a lack of enthusiasm but with outright hostility.

How did this happen? How does a framework go from dead on arrival to the most used library on the web in less than a decade?

In the opening pages of Contingency, Irony, and Solidarity, Richard Rorty makes the assertion that “interesting philosophy is very rarely an examination of the pros and cons of a thesis.” This is a classic Rorty head-scratcher. Isn’t examining the pros and cons of a thesis the primary thing folks do in philosophy?

He continues: “Usually it is, implicitly or explicitly, a contest between an entrenched vocabulary which has become a nuisance and a half-formed new vocabulary which vaguely promises great things”. In my reading, Rorty is making a historical observation, not a value judgement. Many of the things we now look back on as major turns in the history of ideas were not continuations of existing ideas with minor academic squabbles around the edges. They tackled problems so foreign to those being asked, in language so different from that being used, that they were seen as an intriguing novelty rather than a threat. Then they crept up on people, who found themselves almost subconsciously using the new words and asking the new questions.

Rorty’s characterization of interesting philosophy applies equally well to React. It was a half-formed vocabulary filled with unproven new concepts and mental models.

Every other framework at the time [was doing] two-way data binding and… it was like, forget about data binding, we’re not gonna do that at all. Anytime anything changes we’re just going to re-render.

Consider the initial reactions of people who would go on to be core contributors and evangelizers of the library: “Honestly I thought it was completely crazy… there was no way that was going to work.” “The whole bid here was that this would be simpler, but I can’t help but feel like this is really complicated.” “It was so far outside everybody’s idea of how things should work.” The syntax and structure of React code looked entirely different from existing web applications, and the problems that arose in React apps were foreign. But it promised something great.

In the documentary, Christopher Chedeau relates a meeting he had with Jordan Walke about the nascent React in which he asked, What is the most difficult thing to do in the frontend right now? Jordan’s answer was updates; specifically, finding and changing individual DOM nodes. Anybody who has worked with jQuery can confirm that this is indeed a painstaking processes.

If you ask web developers today the same question, nobody will talk about finding and updating DOM nodes. When you write applications in React, updating individual DOM nodes is not something you spend much mental energy on. To be sure, it’s is still doing this under the hood (and understanding precisely how is an invaluable skill). But the problem is abstracted behind the framework. In fact, having to manually reference individual DOM nodes or imperatively update them is often a sign that your code can be improved.

Rorty argues that the method of philosophy he advocates “does not pretend to have a better candidate for doing the same old things which we did when we spoke in the old way. Rather, it suggests that we might want to stop doing those things and do something else instead”. Similarly, React did not propose a better candidate for what was once the hardest problem in frontend web development; it suggested that we do something else entirely. And the same applied to numerous aspects of developing applications, from file structure to separation of concerns to mental models to state management.

Of course, countless hours of engineering and design and advocating, as well as the backing of Facebook, were a big part of why React came to fruition and persisted through intense derision. But React also succeeded because of its lack of incrementalism; its rejection of best practices; its rephrasing of the core questions. React did not solve the old problems of frontend web development. Rather, it dissolved them by rephrasing how a web page is rendered. It replaced them with new, slightly less annoying problems. React vaguely promised great things, and as people tried it out, they discovered that it delivered.

A decade later, the tables have turned. When React was open-sourced, JSX was the most mocked aspect of the library; now JSX feels more natural than HTML. Having done most of my professional work in React, I often find it difficult to shift into an imperative mental model. When I want to play around with a new web API, I don’t add a <script/> tag to an HTML file; I fire up a simple React app.

The fact that React is now thoroughly entrenched means that perhaps we should be on the lookout for another new vocabulary that vaguely promises great things. I think local-first software is a great candidate. I noted earlier that React developers would be unlikely to cite updating DOM nodes as the most difficult problem in frontend web development. So what would they say? My answer would be synchronizing state. And just as React dissolved the question of updating DOM nodes, nascent local-first projects are all about abstracting away the problem of state synchronization. Similar to React’s ‘just re-render everything’ idea, the local-first ‘just cache everything’ ideal seems absurd when you first hear it. But on further reflection, it becomes tantalizingly simple. That will never work... right?! There’s only one way to find out.

Our passional nature not only lawfully may, but must, decide an option between prepositions, whenever it is a genuine option that cannot by it’s nature be decided on intellectual grounds.

William James

I’ve recently been studying William James’ famous essay “The Will to Believe”1, which he describes as “a defense of our right to adopt a believing attitude in religious matters”. I think it has a lot to teach about building software.

Before diving in, let’s clarify the goal of the essay. He’s not arguing for the existence of God, or that all rational people should believe in God. It’s a much more limited argument: that belief in God is rational under a specific set of circumstances. When James defends our right to believe, ‘our’ refers to specific group of people: those for whom belief in God is a ‘genuine option’.

What is a genuine option, you ask? To answer that, we need to back up. The essay begins with three important distinctions about choices: they can be either living or dead, forced or avoidable, and momentous or trivial.

A forced choice is self-explanatory: it is one in which we must pick a side. For example, when building a software application, the choice of which programming language to use is forced, because it’s not possible to build at all without doing so in some language.

A trivial option is also pretty straightforward: it’s an option where “the opportunity is not unique, the stake is not high, or when the decision is reversible if it later prove unwise”. A momentous option is the opposite of this; something that is one-shot and difficult to reverse. For software, this last trait is notable, because decisions that are hard to reverse are often the most important to get right.

The most complicated distinction is between live options and dead options. James says that “a live hypothesis is one which appeals as a real possibility to him to whom it is proposed”. He compares them to wires; a dead option “makes no electric connection with your nature”. This means that whether an option is living or dead depends on the person (or people) making the choice. A relevant example in software is frameworks. If we’re developing a new web application and everyone on the team has lots of Python experience, Django and Flask are both live options for building our backend. But if nobody on our team has touched Java since Object-Oriented Programming 101, then building our backend in Spring Boot is likely a dead option.

After setting up these three distinctions, James gives one final definition: a genuine option is an option that is forced, living, and momentous. Great! So how does he propose we choose between these genuine options? In an ideal world, we could figure everything out from first principles through the use of reason. You know: examine the facts, weigh the pros and cons, analyze the concepts, and reserve our judgement until we have enough evidence to determine and prove the truth about the matter.

But we all know that things are more complicated than that. “Can we always wait with impunity till the coercive evidence shall have arrived?” Surely the answer is no. As a proof by contradiction, he provides the example of flirting:

Whether you [like me] or not depends, in countless instances, on whether I meet you half-way, am willing to assume that you must like me, and show you trust and expectation. The previous faith on my part… [is] what makes your liking come. If I stand aloof, and refuse to budge an inch until I have objective evidence… ten to one your liking never comes.2

What he’s is getting at is that sometimes access to the truth requires us to act on a prior assumption about what that truth will be; and even more radically, that such assumptions can actually affect the truth. There are “cases where a fact cannot come at all unless a preliminary faith exists in its coming… where faith in a fact can help create the fact”. Our belief about what the truth will be play a causal role in what that truth turns out to be. If we aren’t willing to act on faith—if we don’t have the will to believe—we risk missing out on an entire class of truth. And for James, "a rule of thinking which would absolutely prevent me from acknowledging certain kinds of truth… would be an irrational rule”.

With all the pieces assembled, we can finally appreciate his thesis: “Our passional nature not only lawfully may, but must, decide an option between prepositions, whenever it is a genuine option that cannot by it’s nature be decided on intellectual grounds.” The remainder of the essay lays out why religious decisions in particular fall into this category. I think software architecture decision do too.

Martin Fowler has a page about software architecture where he attempts to answer the question ‘What is architecture?’. He offers a couple possible answers: “the decisions you wish you could get right early in a project” or “the important stuff, whatever that is”. I think James’ definition of a genuine option is an even better answer. Architectural decisions are forced; we cannot opt out of them. Architectural decisions are momentous; they are crucial to the long-term success of an application and very difficult to reverse once made. And while some architectural options are dead (if we need a cross-platform mobile app, we aren’t going to write it in Swift), the really important decisions are between live options: choices where we really could see ourselves going down one road or another, and it’s unclear which is best.

Software engineers often find themselves in a state of analysis paralysis when presented with big projects. The sheer quantity of new technologies, tools, and frameworks constantly inundating us only make matters worse. But delaying leads us to the same mistake as the dogmatic skeptic: trying religiously to avoid errors, we end up missing out on truths. For choices that are trivial or avoidable, there’s no rush. But when it comes to the architectural choices, we should consider which options are truly live for us—based on our unique requirements, experience, or interests—and then begin building.

We cannot make architectural decisions on purely intellectual grounds, because the benefits and drawbacks of a given option don’t become clear until we have begun to chisel out real code. Like the question ‘do you like me or not?’, the question ‘should I architect my software this way or not?’ cannot be abstractly analyzed until we have a perfect answer; the answer is dependent on our actions. Waiting for all the evidence before deciding will leave us paralyzed, because the evidence comes only from building the application! With James, we can claim a right to believe. We “not only lawfully may, but must” architect software based on our passional nature.

Might we end up wrong, tearing our hair out as we are forced to refactor everything? Of course! But that is the risk of seeking truth. A decision to delay is just as passional, yet provides no possibility of discovering the right path. The essay ends with a quote that sums this up beautifully:

We stand on a mountain pass in the midst of whirling snow and blinding mist, through which we get glimpses now and then of paths which may be deceptive. If we stand still we shall be frozen to death. If we take the wrong road we shall be dashed to pieces. We do not certainly know whether there is any right one. What must we do? ‘Be strong and of good courage.’ Act for the best, hope for the best, and take what comes… If death ends all, we cannot meet death better.

So the next time someone is arguing with you about architecture in a pull request, just respond with that quote, and I’m sure they’ll let you merge.

Subscribe now

As wonderful as many of these resources are, strangely absent are discussions of why ‘pragmatic’ is an appropriate name for the specific style of engineering being advocated. Perhaps some would say that a pragmatic engineer values real-world results over theory, or delivers improvements incrementally, or is not dogmatic, or focuses on impact. But many of the greatest feats of software engineering have come from people working on seemingly unimpactful problems and operating in decidedly dogmatic, non-incremental, or theory-laden ways, a fact often discreetly brushed under the table.

Usually, ‘pragmatic’ comes off as merely a filler word selected for its friendly connotation. At times it nefariously joins forces with phrases like ‘clean code’ to become a vague stand-in for all that is good and right in the world, and thus a conversation-stopper. Once you define your style as ‘pragmatic’ or ‘clean’, arguing against it becomes futile. (Of course, this sort of conversation-stopping is deeply anti-pragmatist.) A word which stands for everything stands for nothing—some excavation work is needed.

During college I became enamored with philosophy, and ever since I’ve kept up an on-again off-again personal study. These days I’m most interested in the history of philosophy. It is dazzling to peruse the vast array of ideas that have been held dear by human beings over the years and to trace back the often arbitrary and unexpected ways that today’s ideas derive from previous thinkers.

Of all the philosophical schools I’ve come across, the one that cuts closest to my core—the label I am most tempted to intellectually identify with—is called, you guessed it, pragmatism. In the world of philosophy, unlike in software, it refers to something relatively well-defined (albeit hotly debated). Pragmatism is a school of thought which emerged in the United States in the late 19^th century. It germinated in informal discussions of a “metaphysical club” at Harvard and then emerged in the writing and lectures of two great thinkers: Charles Sanders Pierce and William James.

I won’t attempt to give a complete overview of what pragmatism is here; if you’re interested, check out the Stanford Encyclopedia of Philosophy entry. But very broadly, pragmatism is a tradition which insists that change, malleability, and contingency are fundamental features of the world, and that human inquiry and action are inextricable from understanding the world.

Early pragmatists were heavily influenced by Darwinian evolutionary theory, and I find it helpful to understand pragmatism as a philosophical extension of his thought. Darwin discovered that species are not static entities or reflections of idealized forms; they emerge by gradually adapting to external environments, a product of their own natural history. Pragmatists believe that our understanding of the world—our ideas and beliefs—are analogously in a state of flux. Our ideas do not progress linearly towards some metaphysical form and our societies do not march towards some end of history with scientific precision; they adapt, like species, as we continue to inquire and act in the world around us.

Perhaps most incendiary is the upshot of this outlook on truth. Many philosophical traditions accept a correspondence theory of truth: that statements are true insofar as they properly mirror or correspond to external reality. But the pragmatists find this theory useless, because they don’t think a static external reality is something we have access to. It doesn’t do much good to have a theory of truth under which we can’t know anything that is true. They are instead interested in a theory of truth that explains humans come to believe things are true and why true beliefs are valuable. The specifics are a matter great controversy1, but generally involve understanding truth as downstream of the process of inquiry used to arrive at an idea or the consequences of believing it. James put it better than I can: “the truth of an idea is not a stagnant property inherent in it. Truth happens to an idea. It becomes true, is made true by events”2. Crazy stuff, right?

Ok, so… what does this have to do with software? It’s quite straightforward: I believe pragmatist philosophy provides a helpful vocabulary for talking about software. Philosophers have put a great deal of blood, sweat, and tears into clarifying what pragmatism means and working out its consequences, and software engineers would be well served by the usual: copying and pasting someone else’s work, with a few edits to make things run. This blog will be the working out of an extended metaphor: as the pragmatist philosopher views the world, so the pragmatist programmer views software. 

James famously called pragmatism “a new name for an old way of thinking”, and I think this is an apt description for my proposed appropriation of the term too. A philosophically pragmatist undercurrent already ripples through the lingo and culture of software development, but I hope that being explicit about the link between philosophical pragmatism and software yields new insights about how we should create software that a common-sense usage of the word misses or even obscures.

Wilfred Sellars3 wrote that “the aim of philosophy, abstractly formulated, is to understand how things in the broadest possible sense of the term hang together in the broadest possible sense of the term”. That’s a lofty goal, but I think he’s mostly right, and we’ve got to start somewhere. For me, that might as well be software. So that’ll be the aim of this blog, abstractly formulated: to understand how software in the broadest possible sense of the term hangs together in the broadest possible sense of the term.

Subscribe now