[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.


  • 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

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    Free Intro Call

    Book a free 30-minute introduction call with me to see how we could work together.

    Select a time for our call

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>