Last time I left the cap off of the toothpaste, a small blob of toothpaste flowed onto the counter. No planning; it just emerged.

Now I know that emergent software architecture is another thing entirely. We can’t anticipate everything about our software’s architecture before we start building it. It is impossible to get design “right” the first or the second or the third time. That’s why it is so important to iterate. Yet I don’t like to think that good software architecture simply emerges. It’s a bit more complicated than that.

Several synonyms for emerge leave me feeling uncomfortable. I’d rather not have my architecture materialize, loom, or just crop up! Emergent behaviors are a reality with complex software. But emergence doesn’t equate to goodness, no matter how hard you wish it did.

Yet I’m not a fan of big upfront architecture theoretical architecture, either. Emergent behavior can be an opportunity. I like the sense of learning and anticipation in these synonyms: become known, become visible and come into view.

The architecture of complex systems simply has to unfold. We make architecturally relevant decisions based on what we know at any given point in time. And when we don’t know how to proceed we experiment (don’t tell your boss that, call it a design spike instead). Our architectural ideas should change as we write more code and build more of a system. The many micro-decisions we make along the way should lead us to change our minds and our architecture. We shouldn’t have to live forever with bad choices. That’s the beauty of iterative and agile practices. We can fix and repair things. So this is my way of thinking about how good software architecture comes into being:

Good architecture doesn’t emerge; it evolves.

It’s deceptive to say, good architecture emerges. I find that good architecture rarely emerges. We aren’t magicians who materializegood architecture. Good architecture involves hard work, reflection, and paying attention to details. Ideas for architectural improvements emerge from coding. And as long as you have the skills and chops and know-how to make significant changes when they are needed you can improve your architecture. It takes skill to keep your software’s architecture on a good path. Refactoring and redesign is essential. Only when you have the courage (and permission) to refactor and rework your design will your architecture keep pace with your software