[Oldletter #18] Crossing the Chasm, Team Topologies and Solitary or sociable unit tests

📢 Quick announcement: if your team needs any help with building a serverless app on AWS, I may have some availability over the next 2 months to work with you. Just reply to this email and we can set up a call.

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

• Crossing the Chasm (wikipedia link) (1991) by Geoffrey Moore. Pre-eminent book on the journey of technology products into mainstream usage. The author defines five categories of adopters: innovators, early adopters, early majority, late majority and laggards. Critically, each group has different needs and motivations and the “chasm” is between the innovators and early adopters (also termed as “visionaries”) and the early majority (also termed as “pragmatists”).

• Team Topologies (2019) by Matthew Skelton and Manuel Pais. Team Topologies is a framework (with associated book) which defines different team patterns that can exist within a software delivery organisation and the interactions between each.

  Four fundamental topologies:

  • Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
  • Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.
  • Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed.
  • Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams

• Unit test: Solitary or Sociable (2014) by Martin Fowler. The term “unit test” can be very ambiguous and cause unnecessary confusion. This article makes a useful distinction between solitary and sociable styles of unit tests, which greatly helps when recommending which types of tests to favour in a particular context.

  • Sociable Unit Test: Relies on other units to fulfill its behavior
  • Solitary Unit Test: Prefers to isolate the tested unit

---

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