Is Alex Hudson right that software architecture is failing?


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

Also published on Medium.

  • David Link

    I agree, some folks make this business of software development way to complicated, when it doesn’t have to be. I still think Centralized RDBMS is the simplest way to model business processes and and keep complexity down. Thanks for the write up, and pointing out Hudson’s article.

    • Sean Hull

      yep. The field has gotten incredibly fragmented.

      Just a quick look at stackshare is dizzying.

      The other impact is with micro services, you have too much choice. And the language/framework choices are being made casually. The fallout is 3-5 years down the line, the company is saddled with an application stack where they have to support many different languages. How do you hire for that?

    • AlexY

      RDBMS is the simplest way to model business processes? I take it you are a data guy with a hammer? Storage should really be irrelevant and used for… wait for it.. storing stuff, not modeling business processes. I’m surprised to see “business processes”, “RDBMS” and “low complexity” in the same paragraph, let alone same sentence – have you see crazy views, stored procedures of thousands of lines, etc.?

      The fact that RDBMS got so much development was purely due to this obsession with centralization of everything (hello mainframes?) and no need to support high loads / concurrency from the global market.

      There is a reason smart people came up with SOA, EDA, DDD, CQRS. And that is definitely a much better way forward than keeping RDBMS around for business processes and business domains.

      • Sean Hull

        Thanks for the passionate response Alex.

        • AlexY

          Haha. Didn’t feel too passionate, but yeah, maybe a tad too emotional 🙂

          • Sean Hull