Pragmatic Book Club: Chapter 2

We split chapter 2: A pragmatic approach across two weeks in order to stick to our limit of one hour of reading and 45 minutes of discussion per week. I was away on holiday for these two weeks but my very thoughtful colleagues Jennifer Shepherd and Rowan Manning ran the sessions and the questions here are from them.

Following some slightly off-key framing in the first chapter, which covered the pragmatic philosophy, the team was excited to get into less controversial topics in Chapter 2, which covers software design principles.

Chapter 2, topics 8–11

Framing from Jennifer:

I’ve really enjoyed getting into the coding part of this book — it reminds me of when I first started at Makers Academy in 2018 and had lots of enthusiasm (and naivety!) about how beautiful and tidy all my applications could be!

DRY — The Evils of Duplication

To what extent does this reflect your experience at the FT:

We spend a large part of our time in maintenance mode, reorganising and re-expressing the knowledge in our systems.

Maintenance is not a discrete activity, but a routine part of the entire development process.

• Can you think of places this happens in the FT.com codebase? How easy would it be to reduce this?
• How often do you find yourself having to change the same thing in more than one place across FT systems?
• To what extent do you feel our communication methods at the FT help to reduce duplication across teams / groups? Where do you think we can improve?

I loved reading and thinking about duplication in documentation. So often I see out-of-date documentation and spend (waste) time reconciling the docs with the code I’m reading. I love comments in code in places where tricky or unexpected things occur, but I think we can do better at avoiding conflicts between comments / code / docs.

• Where do we do this? Do you have experience of using tools that auto-create documentation?

Orthogonality

Again, love decoupling. Self-sufficient components that can be reused and rewritten and reintegrated?? This is the motivation behind “no next Next”, and I guess the Sugababes.

• Do you avoid writing tests because what you’re testing is not sufficiently decoupled? (broken windows theory…)
• Have you been able to improve our codebase by decoupling when you’ve made a change?
• Here’s a similar question directly from the book relating to bug fixes:

When you make a change, does it fix everything, or do other problems mysteriously arise?

Reversibility

If you rely heavily on some fact, you can almost guarantee that it will change.

• Do you have any examples of this? Where have we benefitted from expecting change?

You also need to think about maintaining flexibility in the areas of architecture, deployment, and vendor integration

I’ll end on a reflection that all of this sounds ideal but it is a lot to think about at the same time, especially for those of us who haven’t got 20 years of experience. It reminded me of the value of having diverse teams with varying strengths and depths of experience in each of these areas. And how great it is to run things past our lovely colleagues so that we can find our current blind spots!

If you use the principle of orthogonality, combined closely with the DRY principle, you’ll find that the systems you develop are more flexible, more understandable, and easier to debug, test, and maintain.

[Bonus question from Rowan] Interested to know generally, with reversibility how much do you think this conflicts with the idea of premature optimisation? What is the right level of preparedness for change?

Chapter 2, topics 12–15

These prompts are from Rowan Manning:

I generally found myself taking fewer notes on these topics, but can’t decide whether that’s because I know them or just find them less interesting than topics 8–11. Possible questions to raise in the book club are bold-italic.

Tracer Bullets

I’ve never called it tracer code but this but working on a single vertical slice of the codebase makes sense to test that all the layers can interface with each other checks out.

• Is this something you find you’re able to do at the FT?

Prototypes and Post-it Notes

“Make sure everyone understands that you are writing disposable code”.

• How have you achieved this in the past? How successful was it? Do we have any prototypes in production?

Domain Languages

I did find this topic quite interesting, it got me thinking about whether there are any areas we could write our own domain languages to simplify parts of our estate. Is there something here in relation to helping other teams integrate with FT.com? E.g. Slack’s Block Kit is a domain-specific language for defining the UI and UI interactions in their app, and it’s incredibly powerful

• Do you use any Domain Languages in your day-to-day work at the FT? Do they confer the benefits suggested in this topic?

Estimating

Interesting note on whether someone’s looking for high accuracy or ballpark estimates. Giving them a ballpark when they’re expecting high accuracy is a recipe for disappointment

I found this topic a little dry and the way we work [in my team] doesn’t result in a lot of time-based estimation lately. I may start tracking my own estimates anyway, even if they’re more personal targets than anything else.

• What methods do you use for estimating in your teams? Are they accurate, or are they at least getting more accurate over time?