Beautiful code ≠ functional code
Clean code and functional code are not the same thing. Sometimes they’re opposites. This idea has clattered around my brain since reading Seeing Like a State.
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, while 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.
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 its complexity - extracting procedures into methods or invoking some metaprogramming to make an ’elegant’ solution. While sometimes helpful, this neat, clever, clean code often makes things harder to understand or reason about. It imposes visual order at the expense of functional order1.
Visual order and functional order are independent properties. Highly functional code does not necessarily look beautiful — and that’s fine.
What does ‘functional order’ mean in relation to code? For me, it encompasses its strictly functional requirements (it gives correct outputs for given inputs) but also nonfunctional requirements - for example understandability or debugability. ↩︎