If the highways are crowded, and they build more lanes, the highways get more crowded. If development is slow, and you add resources, development gets slower. Adding people to a project increases the capacity for activity. Activity doesn’t translate to outcomes. In these cases, you’re adding capacity to the system for cars, or for work, …
Always consider your design a subsystem. Jabe Bloom When we build software, we aren’t building it in nowhere. We aren’t building a closed system that doesn’t interact with its environment. We aren’t building it for our own computer (unless we are; personal automation is fun). We are building it for a purpose. Chances are, we …
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 …
The magic of a gelled team is that they know how to work together, and together, they know how to do particular work. The members don’t know how to work together; the team does. These learnings don’t reside in the members individually, the learnings are in the interrelations. A shared know-how is jointly constructed between …
TL;DR: the most productive development happens when one person knows the system intimately because they wrote it; this is in conflict with growing a system beyond what one person maintains. Let’s talk about why some developers, in some situations, are ten times more productive than others. hint: it isn’t the developers, so much as the …
TL;DR: Study all the interactions between people, code, and our mental models; gather data and we can make real improvements instead of guessing in our retros. Software is hard to change. Even when it’s clean, well-factored, and everyone working on it is sharp and nice. Why? Consider a software team and its software. It’s a …
Read moreCode and Coders: components of the sociotechnical system
Developers have a love-hate relationship with code re-use. As in, we used to love it. We love our code and we want it to run everywhere and help everyone. We want to get faster with time by harnessing the work of our former selves.And yet, we come to hate it. Reuse means dependencies. It means …
“And the Delivery team is in charge of puppet….” said our new manager. “Wait we’re in charge of WHAT?” – me “Well I thought that it fits in with your other responsibilities.” “That’s true. But we’re not working on it, we’re working on these other things. You can put whatever you want in our yellow …
Can you take a piece of data in your system and say what version of code put it in there, based on what messages from other systems? and what information a human viewed before triggering an action? Me neither. Why is this acceptable? (because we’re used to it.)We could make this possible. We could trace …
Systems (and by “systems” I mean “everything”) can be modeled as stocks and flows.[1] Stocks are quantities that accumulate (or disappear) over time, like money in a bank account or code in your repository. They may not be physical, but they are observable in some sense. Flows are how the stock is filled, and how …