Most people regard tech professionals as dull people they don’t want to get stuck with at a dinner party, but if you’ve worked in tech for any period of time, then you have likely encountered a degree of passion for their preferences that would surprise most people unfamiliar with the field.
Some of them are so intense that they’ve been called ‘holy wars’, for example flame wars about something as mundane as text editors have gone on for decades. (Team vim, for the record).
I think this touches on a deeper truth about the nature of our work that is under-explored, and that I want to expand on here.
Architecture
First I want to take a sharp left turn, and try and relate this to something we can all understand: architecture.
Which of these two buildings’ entrances do you prefer, and why?
This?
or this?
How about this:
or this?
I don’t know which you preferred (and it’s a tiny sample), but I might be able to guess some of the reasons you might articulate for picking one over the other:
- ‘Clean’ vs ‘Messy’
- ‘Ordered’ vs ‘Disordered’
- ‘Plain’ vs ‘Interesting’
Obviously, there’s no right or wrong answer, but we can examine our responses and think about where they come from and why.
Classical vs Gothic
Some readers may have noticed that both pairs of images contrast a ‘classical’ building first with a ‘gothic’ second one. Definitions of what a classical versus a gothic building vary. Some look at the decoration, and if they see columns like this:
then it’s classical, and ornament like this:
makes it Gothic.
But you can look deeper than this, and consider the philosophy that underlies the decoration.
Classical architecture tends to seek to make its buildings orderly. The decoration is consistently applied, and laid down by historical precedent. Its exteriors and internal rooms are symmetrical, their dimensions often regular shapes such as cubes. It looks man-made, and seeks simplicity and repetition over complexity and detail. By contrast, gothic architecture loves fine detail and complex patterns. These details may be repeated across the building, or one-offs in their particular spaces.
Gothic architecture often allows for buildings to grow asymmetrically (or ‘organically’) without spoiling an overall design or need for symmetry. The shapes used are not Platonic ideals like cubes or circles, but more individual/unique fractal-like variations on them.
This is where classification gets difficult: many so-called gothic buildings look very symmetrical, and some so-called classical buildings can have very fractal-like decoration or asymmetry. Throw in styles like baroque, which revelled in fine asymmetric detail while embracing traditional classical forms, and it can get very confusing indeed.
Ruskin was a 19th century thinker who thought very deeply about these classifications, and his preferences, and came up with profound reasons to justify them. His writing ranged over art and aesthetics to architecture and its relation to society and economics, and, ultimately, morality and ethics.
He argued that what made gothic architecture gothic was a fundamentally different world view that resulted in these differences. First he separated out what made gothic and classical different without looking at the detail of ornament:
| Gothic | Classical |
| Organic | ‘Ideal’ |
| Responsive | Platonic |
| Diachronic (changes over time) | Synchronic (a fixed ‘snapshot’) |
| Individual | Collective |
| Human scale | Corporate scale |
This might start ringing bells with some readers working in tech, as it’s very close to the central metaphor in Raymond’s book ‘The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary’.
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. In the book, he was talking about different kinds of free software development (centrally controlled contributions and release vs Linux-style distributed contributions and releasing), but 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 the exact same word to describe what kind of architectural style (or ‘ornament’) he preferred. He divided these into three:
- Servile ornament, in which the execution or power of the inferior workman is entirely subjected to the intellect of the higher
- 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
- Revolutionary ornament, in which no executive inferiority is admitted at all.
For Ruskin, it didn’t matter what the object ended up looking like. What mattered was how much freedom the craftsman (it was almost always a man in medieval times) had when making it. The more freedom the craftsman had, the less a slave they were to some higher authority, and the more humane the society was that produced it.
What Does This Have To Do With Technology?
Let’s look at Apple’s headquarters. You’ve already seen it in one of the images above, but here’s another, wider view.
Put bluntly, you can’t get more classical than this. There’s barely any ornament here at all, no room for organic growth, and clean lines and ideal forms are everywhere.
You might think it’s delightful, but I find it disturbing. What does this say about Apple’s relationship with its workers? Where do I put my bag? Where do I sit down? Where do I wipe my feet?
Look at this picture again:
For me, those people spoil that view. Those irregular blobs of flesh and mostly water just ruin the symmetry of the place. Can’t we just do away with them?
This building doesn’t accommodate people, it admits them on sufferance.
The design of this building is no accident. It was overseen by Steve Jobs himself, and he ‘wanted no seam, gap, or paintbrush stroke visible for a clean fit and finish’.
It wasn’t just that building either. Nothing says ‘we have mastered nature and know better than you’ than putting a glass cube in downtown New York:
And if you think this doesn’t matter or mean anything, that it’s just aesthetics, then consider these two stories. The first is about the building itself:
Surrounding the Cupertino, Calif.-based building are 45-foot-tall curved panels of safety glass. Inside are work spaces, dubbed “pods,” also made with a lot of glass. Apple staff are often glued to the iPhones they helped popularize. That’s resulted in repeated cases of distracted employees walking into the panes, according to people familiar with the incidents.
Some staff started to stick Post-it notes on the glass doors to mark their presence. However, the notes were removed because they detracted from the building’s design, the people said.
https://www.thestar.com/business/2018/02/19/apple-employees-encounter-pains-of-glass-at-new-spaceship-campus.html
I don’t think you can get anything more dehumanising, anti-organic, or plain evil in architecture as removing safety measures people themselves have taken to defend themselves against a hostile building because it doesn’t match the ‘clean fit and finish’ of the building.
The second goes beyond the HQ building to the products Apple produce. Most famously, Steve Jobs’ foray into customer support involved him instructing users to not hold the device in the natural way. This was popularly characterised as him saying “you’re holding it wrong”.
You’re holding it wrong, you’re walking around wrong, you’re putting post-its on dangerous glass doors wrong. You’re the problem, mate.
The highly influential ‘Design of Everyday Things‘ by Don Norman explicitly calls out this kind of thinking as wrong-headed, under the heading of ‘human-centred design‘. Interestingly, Norman worked at Apple in the 90s, and I can’t help but speculate whether these philosophical differences ever caused tension there.
Programming Languages
Once you start thinking about how building encourages or discourages a means of living compatible with a human, creative and dynamic life, then you start to see it everywhere.
Take programming languages. On the one side you have Java, top-down designed from the start to enable ‘superior minds’ to impose a limited domain of control on inferiors: use the class hierarchy we have given you; if you must write your own code, then use the Standard Libraries, which have been created to stop you from making mistakes.
On the other end of the spectrum, you have Perl, where “there’s more than one way to do it”, and games like Perl golf, allowing the individual to be creative in pursuit of their goal. The approach to the individual developer couldn’t be more different.
Where does your favourite language fit?
It’s not my intention here to argue that Perl is wonderful and Java is awful. I like neither. My intention is to point out that our preferences may reflect a deeper set of beliefs that we may want to reflect on.
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 Golang (a relatively young language) projects abound. I can’t help but think that that’s because in our spare time, we want to work on a language that gives us the freedom to be somewhat creative. But the ultimate creative language (in my view), 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.
Java can hardly be regarded as a failure. I’ve met plenty of highly creative Java programmers. It makes so many things so much easier for the typical developer that its persistence has to be respected. And the ‘freedom’ of Javascript has hardly resulted in a 100% safety record.
Classicism has similar reasons for its persistence: in Britain, its uniformity and well-defined rules allowed those architects that followed the trailblazers (Inigo Jones, Wren) to create cheaper versions of their work that looked good enough to be fashionable.
Vitrivius Britannicus was the ‘Design Patterns‘ of its day, giving architects a copy-book of easy-to-follow examples for building grand houses in Britain (and then, later, America) that more or less look the same.
This style was called Palladianism, and became ubiquitous because it was quite difficult to mess up, as long as you knew the basics: how to keep things symmetrical, and draw straight lines. To me, this is Java, not Perl.
And back to Ruskin, Victorians did similar, by copying the patterns of Gothic decoration in a uniform and cheap pattern-book way, an ironic result for the frustrated Ruskin. I grew up going to churches that looked like this in East London:
These are essentially classical buildings with some pointed-arch windows and coloured bricks instead of columns and marble. Not much outlet for the creativity of the ‘individual craftsman’ there.
Structure of Projects – Agile
Which brings me to agile. Like Ruskin’s influential preference for Gothic, Agile’s original stated intention was a simple one:
Notes on the above tenets relevant to this discussion:
- 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 – emphasise the importance of the individual’s contribution to the overall product
- 8, 11, 12 – emphasise the importance of personal relationships to the overall product
Note how many of these tenets are related to things that can’t easily be automated, defined or schematised. 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 the bottom-up, gothic, bazaar way of working.
So how do you answer that favourite water-cooler conversation: how agile is a team? I suggest you ask yourself this question: 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 demands enterprises must fulfil 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 that’s not what makes sense for your business. But if the individual’s fulfilment and creativity isn’t a primary concern then just own that, and make sure the overall project is something people can make sense of.
To my taste, this is a really beautiful building, even though it’s about as classical and ‘ideal’ as it’s possible to be:
Why? Because although nothing can be moved, 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: designed for people to be in and contemplate the demise of other humans.
Compare with this one:
The British Museum, 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 have a look.
So if you are going to be classical, to try and reach for an ideal, make sure that the centrally-designed systems make room for a human to be productive in, not just because it’s more correct, but because it’s important that what we do is not designed to turn us into cogs in a machine.
The last word goes to Ruskin. If we’re anything, we’re ‘fragments of imperfection’:
‘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.’
Ruskin, The Stones of Venice
If you like this, you might like one of my books:
Learn Bash the Hard Way
Learn Git the Hard Way
Learn Terraform the Hard Way
zwischenzugs 
Good one Ian! thanks, man!
Loved it! Thanks, Ian.