Tag Archives: overengineering

Is Alex Hudson right that software architecture is failing?

via GIPHY

I read Hacker News aka Ycombinator’s popular top 100. I never fail to find useful, surprising & stimulating reading there.

I recently stumbled on Alex Hudson’s software architecture is failing.

It’s very good, I recommend reading it.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

But why did it grab my attention, you might ask? Perhaps I’m a naysayer. But I do find there is a lot of hype, and a lot of sex in software today. It’s as though the shiniest, newest, coolest toys are the ones getting the spotlight.

So when I find an alternative view, I sit up and take notice.

1. Are we making systems too complex?

Right out of the gates, Alex makes a great point:

“We’re not delivering quickly enough!”. “Our systems are too complex to maintain!”. “The application we delivered last year is completely legacy now but it’s too difficult to replace!”.

Our industry’s obsession with the newest & coolest toys, means we’re building things that don’t last very long. A real & ongoing problem.

Related: Why does Reddit CTO Martin Weiner advocate boring tech?

2. Smaller enterprises

One thing Alex pointed out that really struck a nerve was this:

For those in tech who are not working at Facebook/Google/Amazon, we’re simply not talking enough about what systems at smaller enterprises look like.

I couldn’t agree more. As a profession, we watch closely at what the big guys are doing. And that’s useful to a point. But for many smaller companies, to use such architectures would be over engineering in the extreme. Not to mention extremely costly!

Related: How I use terraform & composer to automate wordpress on AWS

3. Not bleeding & far from the edge

Another choice quote from Alex’s piece:


“It’s totally legacy, and no-one maintains it – it just sits there working, except for the occasions it doesn’t. The problem is replacing it is so hard, it’s got great performance, and the business doesn’t want to spend time replacing something working”. This is the problem being ahead of the curve – the definition of “success” (it works great, it’s reliable, it’s performant, we don’t need to think about it) looks a hell of a lot like the definition of “legacy”.

We know the term bleeding edge because it’s tough being out there trail blazing. Here I agree that sometimes legacy is also boring, yet eminently reliable.

Related: 30 questions to ask a serverless fanboy

4. Reduce, reuse, recycle

Should we build it or should we buy it? Here’s what Alex says:


I think we’re often getting the build/buy decision wrong. Software development should be the tool of last resort: “we’re building this because it doesn’t exist in the form we need it”.

Well said. Sure we should consider integration costs & testing. And using a service brings other things to balance. But it means we don’t have to own that code.

Better to focus on our business core competency.

Related: Is Amazon about to disrupt your data warehouse?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters