# On Software architecture: Some Honest thoughts

 I've been meaning to write this for a while. Not because I have a definitive take — I don't — but because writing things out is how I process them, and software architecture has been occupying a disproportionate amount of my thinking lately.

Let me start with what prompted this.

About three weeks ago, I was working on something fairly routine in Software Architecture when I hit a wall that didn't make sense on paper. Everything looked right. The framework was sound. The process was being followed. And yet the result was off in a way that I couldn't immediately explain.

I spent a few days going back through the logic before I realised the issue wasn't in the execution. It was in the assumption I'd carried in at the beginning — specifically around software architecture. I had treated it as a settled question when it was actually still an open one.

That's the kind of thing that sounds obvious in retrospect but is surprisingly easy to miss when you're in the middle of it.

The first thing is how I categorise problems in Software Architecture. I've had a habit of sorting things into 'solved' and 'unsolved' — and once something lands in the solved column, I stop interrogating it. Software architecture had quietly migrated into that column, probably a year or two ago, without sufficient justification.

The second is the relationship between software architecture and system design. These two things get treated as separate in most of the frameworks I've encountered, but in practice they interact constantly. A change in how you think about one immediately affects the other. Treating them in isolation is a simplification that costs you accuracy.

The third — and this is less Software Architecture-specific — is the value of being wrong in a useful way. Not just wrong and confused, but wrong in a way that points somewhere. The wall I hit three weeks ago was frustrating in the moment, but it updated something in how I think about software architecture that I don't think I'd have reached any other way.

I've been spending more time with tech conventions outside of work hours. It started as a way to decompress, but I've noticed it's also become a useful counterpoint to work thinking. There's something about a context where the rules are clear and the feedback is immediate that makes the ambiguity of Software Architecture feel more tolerable.

I'm not sure what to do with that observation except note it. Maybe the value of hobbies for people doing ambiguous professional work is more than just rest — it's also contrast. A reminder that not everything has to stay open.

I don't have a tidy conclusion about software architecture. I have an updated set of questions and a slightly less confident set of assumptions. That feels like progress, even if it doesn't feel like resolution.

If you're working in Software Architecture and software architecture is something you think about too, I'd genuinely be interested in what you're seeing. The most useful thing I've found in situations like this is comparison — not to find the right answer, but to get a better map of where the hard parts actually are.