Arguing about the Shape of Water

When we want to discuss an abstract concept in software, we reach for a metaphor.

For instance, when we want to describe being quick and nimble, able to react to any change the world throws at us, we say we’re agile. When we try avoid over-powering development processes that push us toward the inevitable edge without letting us pause to reflect and learn, we say we’re avoiding waterfall.

But no metaphor is safe from the petrifying effects of pop culture. Once the industry gets ahold of an idea, it gets commoditized. It gets its own conferences and certifications. It gets consultants. After a while we stop looking through the metaphor to the deeper idea and start looking at the image of the metaphor.

We end up ranking and comparing the metaphors, taking sides, and have endless debates. It’s like arguing about which shape of water is the best.

Aren’t we all trying to talk about the same things, though? We all want to build good software that we can change and evolve. We all want be able to handle changing requirements as a business advantage. Microservice or monolith, agile or waterfall, object oriented or functional, static or dynamic typing, REST or RPC. We all want to bend software to our will rather than be at its mercy.

For me, returning to the mystery of the metaphor means moving from “Well, actually…” to “I don’t know” or “It depends…” or “Hmm, what do you think?” It means flipping the discussion upside down so beginners can teach the experts—you don’t have to know about SCRUM to talk about ways to work better together.

It’s a bit like understanding the shapelessness of water by talking about the water’s shape.