At Papers We Love conference, Dr Heidi Howard described requirements for distributed consensus: Safety and Progress. In distributed consensus, multiple servers decide on some value and then report that to their clients. Safety means that the clients never learn about different values; the consensus is all correct and consistent. Progress means that clients do eventually …
We prefer simple models to complicated ones. Circles to ellipses, a single ancestor to a soup. But is that really because the simple explanation is more likely? The value of keeping assumptions to a minimum is cognitive. Philip Ball, The Tyranny of Simple Explanations Simpler theories are more useful because we can think about them …
businesses… need a new worldview… that shifts the emphasis… from success as accomplishment to success as learning. Jeff Sussna, in Designing Delivery “Success as learning” doesn’t mean learning lessons. This is not learning as facts. This is learning as becoming. It is learning that bakes into who we are and how we do things, bakes …
Legacy code is software that is no longer alive in someone’s head. No person has a mental model of how it works, no one has the stories of why. This is already the common case in software systems, and it will only grow more normal. Understanding an entire piece of the system is a luxury. …
You can want something, or you can just be interested in things. On a dating site, you can decide what you want in a partner and filter people for that and message them. Or, you can find many things about people interesting, and look for any of these traits or hobbies, and ask about them. …
Some people work in a system, and some people work on a system. Like, you can be the person who washes the dishes, or the person who installs and maintains the dishwasher. You can be the person who assembles the reports every week, or the person who automates that report assembly. (Jacob Stoebel told this …
I am locally very important, globally not important. It helps that I’m not important, that the world moves on whatever I do, it doesn’t need me to push it The people close to me, they count on my help. Local systems, my family and my team, what I do matters to them. Failing them, this …
To scale up the system you’re changing, scale down the changes. The bigger and more complex the system you’re working on, the more people involved, the more affect a change can have — the smaller each change needs to be. When change is expensive, when it’s scary, don’t make fewer changes. Work to make changes …
There’s a story about some brilliant design that made carrots more accessible to everyone, and the man who made it happen: Sam [Farber], a delightful person to work with. He understood the business, but what was important was, he understood design. If he could have been a designer himself he would have been, but he …
In Projects to Products, Mik Kersten divides flow items in software products in four: features, defects, risks, and debt. If you only count features added and bugs fixed – changes visible externally – then you neglect the other outcome of our work: the next version of the team+software. I prefer to think of “technical debt” …