The more we speculate upfront about what the design should be, the less likely that we’ll build the contextual awareness muscle needed to look at the existing design and ask “what is it trying to tell me that I’m not hearing?”.
»The idea of “on time” as a project health metric is deeply flawed. People get satisfied and excited about it when a project is “on time”, but it essentially communicates overconfidence of people and organizations trying to fit the inherently complex reality into a number they came up with. The truth is: the reality doesn’t give a damn about what we think of it.
»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.
»the usual intervention I observe is introducing more gates on the way to production.
»if they aren’t continuously coaching others on what they know, accelerating knowledge sharing, and helping the whole team speed up.
»is the reduction of the median rate of change across code elements (methods/classes).
»is non-linear in nature, with some exponentiality in it.
»then the refactoring step you plan to do is probably already too big.
»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:
»