[Oldletter #10] Small batches, the no-code delusion and why SOLID is wrong

Every Friday, I’m sharing a short list of evergreen articles/resources broadly related to software engineering that wouldn’t typically get shared in most tech newsletters or social media feeds.

My backlog is running low again, so please send me any new recommendations you have.

---

This week’s links

• Small Batches (2022) by Jonathan Hall. 3-post series on why working in smaller batches is so beneficial, both at the macro business level and the micro code/task level. Just reading through these benefits, even if you’re probably already aware of most of them, will make you want to be more deliberate about splitting things up.

  Unfortunately, delaying deployments and batching them doesn’t merely delay the risk, it actually increases the risk. If any given feature has, say, a 1% chance of containing a defect that requires a rollback, then waiting to release 10 of them together means you have nearly a 10% chance of needing a rollback.

• The No-Code Delusion (2020) by Alex Hudson. A piece which elucidates my inner unease about many low/no-code tools. Many of the concerns raised by Alex here are also applicable to functionless cloud integrations and not just non-technical user tools.

  Programmers face this dilemma constantly: do we trust an external system and put a lot of configuration effort into it, or attempt to handle more of the logic ourselves? The logic doesn’t go away. Just because a decision is embedded into the wiring of a Zapier rule doesn’t remove any of the burden of maintenance / correctness.

• Why every single element of SOLID is wrong (2021) by Dan North. The five SOLID principles have been treated as almost sacrosanct in software engineering circles, but Dan argues here that they are outdated and in need of replacing. I particularly like his takedown of the Dependency Inversion Principle (‘D’):

  I don’t think it is an overstatement to say that our obsession with dependency inversion has single-handedly caused billions of dollars in irretrievable sunk cost and waste over the last couple of decades. The real principle here is option inversion. A dependency is only interesting when there might be multiple ways of providing it, and you only need to invert the relationship when you believe the wiring is important enough to become a separate concern. That’s quite a high bar, and mostly all you ever need is a main method.

---

Submitting your recommendations

If you’d like to share an evergreen article/book which has significantly influenced your thinking or practice around software delivery, please email it through to me and I’ll add it to my backlog for sharing in future editions.

Have a great weekend!

— Paul