One of the big benefits of slicing, that I don’t get to hear at all, is that the way we sequence slices by value, as a byproduct also serves as a guide on where are the fracture planes or seams for gracefully degrading business capabilities when things go south in production.
From the “right leverage point, wrong direction” series (reference to Jay Forrester), the majority of teams I worked with when faced with high batch transaction cost relative to batch size, instead of reducing the transaction cost they increase the batch size.
It’s close to impossible to measure good, testable design, but over the years two interesting metrics settled in my mind that are a fairly good indication of the presence of clear, explicit code that speaks the domain:
Some of the things I think about when asked how to influence change in teams/orgs as a Principal/Staff engineer:
Invest time in building relationships before (big) course-correcting. In the start: a productive relationship is more important than being right. Spend time working together with people and sharing the constraints they are facing day-to-day, it will help you understand their context which makes your future interventions more likely to be useful.