If you can't change design cheaply
If you can’t change design cheaply because refactoring skills are lacking, you’re less likely to end up with a suitable design for a given problem that emerges from insights you get as a byproduct of refactoring.
»It's not about reducing the costs per se
I often ask myself if a technology, beside lowering the costs for which lowering the costs is beneficial, is also lowering the costs for which lowering the costs is detrimental.
»Dynamics between transaction cost and batch size is simple, but often counterintuitive.
In short, the system compensates for the increase in transaction cost per batch size by increasing the batch size.
»Managing interdependence over decoupling
The idea of managing (inherent) interdependence in systems is at least as important as the idea of decoupling (independence) that the software development industry is so predominantly obsessed with since the field’s inception.
»Working together (pair/mob/ensemble) helps with fixing inefficiencies in the system
in a way that it amplifies the pain that every single individual felt when working in isolation, but because everyone was suffering alone, the pain was perceived not as high to address it.
»If an incident report
contains more action items related to adding more gates before a change reaches customers, rather than reducing the size of the change, you’ll likely end up with having to create even more incidents reports.
»Let the design guide you
to what it wants to be, instead of you trying to force it into your idea of what it should be.
»The scary thing with overly complex solutions
is that once they persist long enough and are more adopted in the industry, they become familiar solutions.
»The opposite of Extreme Programming
is not Balanced or Safe or Conservative Programming.
»We need fewer assumptions to test
with each deployment (smaller changes), not more delayed feedback (more gates, more branches, etc.).
»