What makes software hard to change? As a developer, it’s easy to focus on the internal properties of the software system. The code needs refactored, the framework is old, we need more tests, or else fewer tests. If your software is in production, these are not the biggest obstacle to change. The important changes are … Read moreInertia in the interface
I have an article up on InfoQ finally, about when correctness matters the most, and when it isn’t really a thing: https://www.infoq.com/articles/correctness-versus-change/
On recommendation from @mtnygard and others, I have acquired a copy of How Buildings Learn (Stewart Brand, 1994). Highlights so far: Buildings are designed not to adapt, but they adapt anyway, because the usages are changing constantly. “The idea is crystalline, the fact fluid.” They’re designed not to adapt because “‘Form ever follows function’ … … Read moreChange at different timescales
Art has progressed from “inner coherence” to contextual, interrelated meaning. Can software get there too?
It is better to practice risky things often and in small chunks with a limited blast radius, rather than to avoid risky things. Charity Majors, “Test in production? Yes“ Charity is writing about deploys. Not-deploying may be safer for tonight, but in the medium term it leads to larger deploys and bigger, trickier failures. In … Read moreTiny dramas, tiny deploys
Our job as developers is to change software. And that means that when we decide what to do, we’re not designing new code, we’re designing change. Our software (if it is useful) does not work in isolation. It does not poof transition to a new state and take the rest of the world with it. … Read moreDesigning Change vs Change Management