Software, Aesthetics, and Craft: How Java, Lisp, and Agile Shape and Reflect Their Culture

The software industry is permeated with metaphors borrowed from architecture and construction. We even call ourselves architects and engineers, have project plans and deliverables, argue over development methodologies and project governance, and time and materials work versus piece work, just as builders do.

While there is a great body of literature on the aesthetics of architecture, the aesthetics of software is rarely discussed. Here, I’m not talking about the design of websites or mobile apps, about which there is already plenty of discussion. In this article, I want to introduce the architectural theories of the Victorian thinker John Ruskin, and apply them to software, in order to surface the underlying philosophies that we invisibly accept, and from that starting point, question them in relation to the languages we use and the Agile movement.

First, let’s try to understand the difference between two basic architectural concepts. It may sound simple, but it quickly becomes fraught.

Gothic vs. Classical — A Quick Primer

If you were asked to describe the two buildings pictured below in two words, you might well pick "Classical" and "Gothic," respectively.

Loosely speaking, Classical buildings look "neat," "ordered," "simple,"

while Gothic buildings look "ornate," "busy," "complicated."

So surely, it can’t be hard to come up with a clear formal definition of Classical and Gothic architecture, can it?

Turns out, it’s surprisingly hard. For example, you could argue that Classical architecture is symmetrical, and Gothic asymmetrical. It’s not hard to find counter-examples of Classical buildings that are asymmetrical, though, and plenty of Gothic buildings are symmetrical. You can argue that flying buttresses are a central feature of Gothic architecture, but St Paul’s Cathedral in London has flying buttresses, and that building is universally seen as in the Classical tradition (specifically, English Baroque), and so on.

You don’t have to look at surface details to identify whether something’s Gothic, though. This is where John Ruskin comes in.

John Ruskin

John Ruskin was an influential Victorian thinker. Today, few have heard of him, but his writings on art were popular in their day, and he has been credited with influencing Tolstoy, Proust, Gandhi, the Labour Party, and the welfare state.

Throughout his work on Art History, Ruskin argued that architecture’s outward forms were not what made them Gothic or Classical. Instead, he argued that their different forms sprang from the societies that created them, and the quality of their society should be the grounds on which their aesthetics should be judged.

To that end, Ruskin identified several more fundamental paired elements that, taken together, made up what he saw as the Gothic and Classical aesthetics.

This talk of architecture, "organic" vs. "ideal," and "responsive" vs. "platonic" may ring bells with some readers working in tech, as it’s close to the central metaphor in Eric Raymond’s book The Cathedral and the Bazaar.

In that book, Raymond contrasts the "top-down" (Classical) design of a cathedral with the "bottom-up" (Gothic) design of a bazaar, and uses those as metaphors for different kinds of software development. He talks about different kinds of free software development, specifically centrally controlled contributions and release versus Linux-style distributed contributions and releases. Here, I want to extend it to any kind of technology, physical or virtual, open or closed.

It’s interesting that Raymond calls the bazaar "revolutionary," since Ruskin used that word to describe what kind of architectural style (or "ornament") he preferred. He divided ornament into three categories:

1. Servile ornament, in which the execution or power of the inferior workman is entirely subjected to that of the higher authorities
2. Constitutional ornament, in which the executive inferior power is, to a certain point, emancipated and independent, having a will of its own, yet confessing its inferiority and rendering obedience to higher powers
3. Revolutionary ornament, in which no inferiority is admitted at all

For Ruskin, it didn’t matter so much what the object ended up looking like, or whether that in itself pleased you. What mattered was how much freedom the craftsman had when making it. The more freedom the craftsman had, the less a slave he was to some higher authority, and the more humane the society was that produced it.

Ruskin’s analysis and perceptions were as profound as they were influential. It’s no coincidence, for example, that 20th-century totalitarian states loved classical architecture (and its natural heir, Modernist architecture). In these states, every individual contribution had to be subordinated to the whole, reflecting all individuals’ subordination to the higher cause, and the architecture reflected this. More democractic states tended to shy away from the extreme classicism of Nazi Germany or Stalinist Russia. The Trump regime’s recent directive on architectural style is an interesting echo of those regimes’ tastes.

Programming Languages

What has this got to do with software? Just as with architecture, there’s no shortage of debate about what the "best" programming language is. But I don’t think I’ve ever heard a debate about languages that centers around what kind of culture the language encourages or enables.

Let’s take a mainstream language, like Java. Java is relatively restrictive and opinionated about how it should be employed. Its original design was intended to encourage engineers to defer solutions to problems to other classes of object. This whole philosophy of the language is not designed to encourage individual creativity or expression. When I think of a large Java project, I think of teams working to a specification that’s centrally defined, and within a centrally-defined framework, to deliver code that performs to specification. Java was designed from the outset to favor simplicity, even stating in the Java language specification: "It is designed to be simple enough so that many programmers can achieve fluency in the language... It is intended to be a production language, not a research language, and so, as C. A. R. Hoare suggested in his classic paper on language design, the design has avoided including new and untested features."

By contrast, Perl, a formerly popular language, has as a central tenet "there’s more than one way to do it," a philosophy that actively encourages and celebrates individual creativity. This does not make for readable code, so it is often joked that Perl is a "write-only" language.

Also, further along on this scale, you have languages like Lisp and TCL, which grant freedom and power to the individual contributor to do crazy things should they wish, like self-modifying code or redefining fundamental components of the language itself.

And yet, Java has won out over these other, more creative languages. Why? Because, while giving freedom to individual software craftspeople can enable great wonders of engineering and beauty, this comes at a cost of large overhead when you try to get large disparate groups of engineers together to collaborate on it. All other things being equal, most engineers would probably want to take on a sprawling Java project over a sprawling Perl project, thanks to Java’s emphasis on simplicity in its core. In other words, beauty and sophistication in software is not conducive to industrial production. It’s cheaper and easier to use more restrictive tools and create less beautiful solutions to problems.

It’s not my intention here to argue that Perl is wonderful and Java is awful. I want to surface that our preferences are not innocent, and reflect a deeper set of beliefs that we should reflect upon and be conscious of.

I find it interesting that (given its age and widespread adoption), Java isn’t the runaway leader of programming languages used on GitHub, whereas Python, Javascript, and Go projects abound. I can’t help but think that’s because in our spare time, we want to work on a language that gives us the freedom to be somewhat creative (while Go is similar to Java in its restrictions, it still has plenty of creative "green fields" to build on). By contrast, Lisp barely registers on GitHub at all. You can have too much freedom, and bazaars are generally a mess without some kind of central design. People generally find Lisp pretty difficult.

Classicism in architecture has persisted for similar reasons. In Britain, its uniformity and well-defined rules allowed those architects that followed the trail blazers (Inigo Jones, Christopher Wren) to create cheaper versions of their work that looked good enough to be fashionable.

There are even Design Patterns-like books of Classical architecture. Vitrivius Britannicus, published 1715, gave architects a copy-book of easy-to-follow examples for building grand houses in Britain (and then, later, America) that follow the same stylistic formulas.

This style was called Palladianism, and became ubiquitous because it was quite difficult to mess up, as long as you knew the basics: keep things symmetrical, lots of straight lines, and monotonously-featured walls. This style is Java, not Perl, embodied in a building: relatively easy to build and pleasant enough to look at, but not rich and diverse.

It doesn’t look like the builders had fun making it, though. You can imagine masons knocking out cornice after cornice, all pretty much the same, while a lone sculptor got to put a few of her creations on top of the building, where few could enjoy them.

Victorians pulled a similar trick with their version of Gothic architecture. By copying the patterns of Gothic decoration in a uniform and cheap pattern-book way, they enraged Ruskin, who felt that they missed the point of Gothic, mistaking superficial decorative features for the fundamentals of beauty. I grew up going to churches that looked like this in East London:

These are essentially Classical buildings with some pointed-arch windows and colored bricks, instead of columns and marble in an attempt to make them "Gothic." Not much outlet for the creativity of the "individual craftsman" there.

Agile and Gothic

Which brings me to Agile. Like Ruskin’s preference for Gothic, Agile’s original stated intention was simply reasoned from first principles:

We are uncovering better ways of developing software by doing it and helping others do it.
     Through this work we have come to value:
     Individuals and interactions over processes and tools
     Working software over comprehensive documentation
     Customer collaboration over contract negotiation
     Responding to change over following a plan
     That is, while there is value in the items on the right, we value the items on the left more. (Manifesto for Agile Software Development)

 These tenets closely follow Ruskin’s thinking about good work coming from organic, human bases:

• 2 — "embrace change" is close to accepting organic change rather than adherence to an ideal
• 4 — the creative construction process requires a close collaboration with the patron: requirements are organic too
• 5 — emphasize the importance of the individual’s contribution to the overall product
• 8, 11, 12 — emphasize the importance of personal relationships to the overall product

Many of these tenets are related to things that can’t easily be automated, defined, industrialized, or schematized. This is a philosophy that encourages post-its, or a big sheet of paper, or just having it out over a beer if that’s what’s needed to find the right way forward. It’s closer to the bottom-up, Gothic, "bazaar," "revolutionary," and collaborative way of working, with few rules and oversight, than the top-down totalitarianism of Classicism, "cathedral," style of industrial obedience.

How do you answer that favorite tech water-cooler conversation: how Agile is your team? I suggest this question instead: how free is the team to make any decision it feels is necessary to get the job done?

Now, freedom and enterprise do not go hand in hand. This is why you end up with enterprise Agile:

At each and every point, the corporate, regulatory, and legal demands enterprises must meet mitigate against the ability of the individual to make an imperfect contribution to the whole. So stop trying, dammit! You end up by subverting the whole, as this talk by Agile founder Dave Thomas covers.

One of the points I want to make here is that there’s nothing wrong with not being Agile, if what you want to achieve is something that can be done by rote, or you need command and control to deliver the goods. If the individual’s fulfilment, creativity, or capacity for innovation isn’t a primary concern, then just own that, and make sure the overall project is something people can make sense of, like Palladian architecture. Quit trying to be Agile just for the sake of it.

Be honest now: how many people can realistically make sense of this?

Taste, Humanity, and Fragments of Imperfection

I think this is a beautiful building, even though it’s about as Classical and "ideal" as it’s possible to be:

Bramante’s Tempietto

I think this because, although nothing in its design can be moved without ruining it, and arguably no-one that worked on it could express their own take on the theme, the scale of the building is still a human one: it’s designed for people to be in and contemplate the demise of other humans.

Compare with the British Museum:

The British Museum: a building that says, "We’ve got your stuff, and we’re not giving it back."

This is a building I’ve always loathed. It feels designed to make you feel small and imperfect compared to its massive, inhuman scale. It’s also boring. Column, column, column, column, all the way round. The sculpture at the top might be interesting, but it doesn’t seem to have been designed for you to closely look at it.

I couldn’t put it better than Ruskin:

"The principal admirableness of the Gothic schools of architecture, that they thus receive the results of the labor of inferior minds; and out of fragments full of imperfection, and betraying that imperfection in every touch, indulgently raise up a stately and unaccusable whole."

Wouldn’t it make for a better society and better software if, instead of blindly following pattern-books and cargo culting development methodologies that might have once worked for other people elsewhere, we creatively — and imperfectly — pplied our intellect and experience to our local and unique situations, creating novel and beautiful solutions that not only "add value," but give us pleasure? After all, if we’re anything, we’re "fragments of imperfection."

About the Author

Ian Miell works for Container Solutions, helping companies adjust to a cloud-native world. Previously, he worked for banks building and running Kubernetes clusters, and before that, built and maintained back-end online gambling systems. He blogs on whatever interests him at zwischenzugs.com.