We talk about “software products” and “product teams.” What does this even mean, “product?” It is not the definition I learned in school. Economics 101: the output of the economy is “goods and services.” Goods, also called “products,” are physical items that you can buy, take home, and have. Like, if you buy a rug, …
TL;DR: When different parts of an organization need to coordinate, it seems like a good idea to help them coordinate smoothly and frequently. Don’t. Help them coordinate less — more explicitly, less often. Software systems get big, and they have lots of parts, and those parts need to talk to each other. Maybe we’re building …
TL;DR: Projects ask teams do what is asked of them; Products ask teams to invent their work. This requires a different way of seeing the world, and not everyone can do it yet. Software is not an up-front investment that pays off over its use. Software is an ongoing concern, an intricate piece of a …
Read moreProject to Product asks more of our software, and more of us
Just now, Avdi had a miserable experience buying curtains. He went to pick up an order that he placed last night, but Lowe’s didn’t have it. The order was sent to the wrong store and it was a huge pain to figure out. Software is hard to get right. And every time we don’t, customers …
If ya know how to do it, stick with the bureaucracy. If you’re building software, it’s always new — you need a generative org with a resilient structure.
Here’s my keynote for 2021, a sequel to Camerata. Follow this link to the video, abstract, and references over at: systemsthinking.dev.
Batching work is more efficient … until cost rises nonlinearly with batch size. Then smaller batches are the most efficient. So don’t delay maintenance!
The most productive developer on a team is usually the one with the most knowledge of the system. Of the code, the business domain, the other software this code interacts with, and the people in the organization who can help. How did they get that knowledge? By working on the system. Weinberg remarks that when …
TL;DR: When you want to build one platform for all your lines of businesses: stop. Don’t. Build systems for each instead. Keep the integrated parts as small as possible. This minimizes costs, while enabling change. A global, unified platform to support all our lines of business! Doesn’t that sound glorious? CIOs puff out their chests. …
Read moreNonlinear increases in complexity make unification excruciating.
I wanted it to be turtles all the way down. (where turtles are objects, or functions)
But it isn’t…