Beautiful code ≠ functional code
A while ago I read the book Seeing Like a State and certain parts of it still clatter around my brain from time to time - this is one of them.
A fundamental mistake that urban planners made, Jacobs claims, was to infer functional order from the duplication and regimentation of building forms: that is, from purely visual order. Most complex systems, on the contrary, do not display a surface regularity; their order must be sought at a deeper level. “To see complex systems of functional order as order, and not as chaos, takes understanding. The leaves dropping from the trees in the autumn, the interior of an airplane engine, the entrails of a rabbit, the city desk of a newspaper, all appear to be chaos if they are seen without comprehension. Once they are seen as systems of order, they actually look different.”
The quote comes after a section of the book about the city of Brasilia - a Brazilian city crafted from nothing in the 1960’s. Inspired by the work of Le Corbusier, it was designed to be a modern city of the future. However, whilst visually striking and aesthetically organised, it proved a challenging city to live in as a resident. The ‘messiness’ of other cities (such as Rio de Janeiro) belied a deep functional order that largely worked well for their residents. The designers of Brasilia confused visual order with functional order.
I believe we also see this pattern in programming. Sometimes, when we come across a complex piece of code we are driven to impose visual order upon it in an attempt to try and tame it’s complexity - extracting procedures into methods or invoking some metaprogramming to make an ‘elegant’ solution. Whilst sometimes helpful, often this neat, clever, clean code can make things harder to understand or reason about. It imposes visual order at the expense of functional order1.
That is not to say you can’t have beautiful clean code that is highly functional, but rather that highly functional code does not necessarily look beautiful.
What does ‘functional order’ mean in relation to code? For me, it encompasses it’s strictly functional requirements (it gives correct outputs for given inputs) but also nonfunctional requirements - for example understandability or debugability. ↩︎