[Software Engineering Oldletter #5] Abstractions, leaky and 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.

---

This week’s links

• The Law of Leaky Abstractions (2002) by Joel Spolsky.

  All non-trivial abstractions, to some degree, are leaky.

  Abstractions allow us to be much more productive developers, but they occasionally break. Having some knowledge of the layer under that abstraction can be of great benefit when they do. I’m showing my age by remembering the pain of the ASP.NET WebForms abstractions that Joel mentions.

• The Wrong Abstraction (2016) by Sandi Metz. Continuing the theme, this covers a problem very common with developers (I used to do this a ton myself)— always looking for an opportunity for future re-use in something I’m building, and creating some code abstraction to faciliate such future re-use. But Sandi describes the pitfalls of this and advocates:

  prefer duplication over the wrong abstraction

• What I learned from Software Engineering at Google (2021) by Swizec Teller. A book review summary on the difference between programming code for an immediate requirement, and engineering it for several future concerns. Swizec provides a great list of directives which are suited to teams of all sizes, not just FAANGs.

  That’s engineering 👉 considering the long-term effects of your code. Both direct and indirect.

---

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