It has been just over a week since I wrote that software architecture is failing, which received a level of response I didn’t expect. The reason I wrote the post in the first place was to set the scene for some future posts I want to write: as I said, I don’t think we talk enough about architecture for SMEs particularly, and I want to spend some time focussing on those. This post described the reason why.
However, one thing was very clear: the post overall, and many of the ideas within it, strongly resonate with a much larger group of people than I expected. I want to reflect on that a little, but first, let’s look at some stats.
The main route I tend to share articles is Twitter. I tweeted out a link to this article only once:
We need to talk about software architecture. And we need to stop pretending we’re Google.https://t.co/xNWV9ryR7m
— Alex Hudson (@ealexhudson) October 14, 2017
I knew within a few hours of tweeting this, that I was getting a lot more interaction than usual. In fact, at the time of writing, this tweet has had 50K impressions and a 10% engagement rate. This is several orders of magnitude greater than my direct following, and while I wouldn’t claim this is “set the world alight” numbers, it definitely experienced some virality.
I think what is most interesting, though, is the actual qualitative feedback I got from the Twitterati:
- lots and lots of “I think this too!” or “I’ve been wanting to say something like this for ages!”. I’ve found it rare in the past that people will go out of their way to talk about how they agree with posts. In fact, it’s usually the inverse – people get in touch more often when they disagree. I was struck by the degree of consensus within the feedback – I would say 95%+ of responses were in significant agreement. Some people disagreed with some of the specifics, while agreeing with the overall point.
- Basically no “You’re wrong” responses. Nobody seems to think the problem doesn’t exist, nobody is suggesting that “more architecture” is the solution. I was quite surprised by this.
- a lot of people took issue with the way I described ES and CQRS. I think these are both complex subjects that deserve separate and specific analysis; my point wasn’t that these patterns are never appropriate. However, I do believe that many applications of them are inappropriate, and I don’t agree with this suitability for MVP-style projects, for example. There’s definitely a difference of opinion here which I think is interesting to explore.
- I do get the sense that many ES and CQRS proponents are quite sensitive to criticism – I read in this that a lot of the discussion about these patterns has been low-quality so far. A number of people described CQRS as “separating read and write” – which I don’t think is accurate, per se, but there is an interesting issue about the definition about what is and isn’t CQRS. It’s similar with ES, although at least with that technology my main criticism of it (which is that many developers are not well-equipped to develop in an eventually-consistent way) is not debated on points of definition.
- Overall, most of the pushback against the post was “I agree that over-architecture is a problem, but I disagree with <example you gave>”. A lot of people see over-architecture as a problem that other people create. There’s a very interesting cognitive problem here: how do we define over-architecture, and how do we measure it / detect it in a fair and quantitative way? I have some ideas here, but I think this is by far the most difficult problem to resolve.
Obviously this is something I would like to write much more about, but I would also love to see a community form around the ideas of planning and executing with simplicity, measurement of complexity, and architecting for speed/agility/maintenance. It’s clear to me that a lot more research and thinking in this area is deserved.