a tiling of the plane by pentagons, in which groups of four tiles form two interlaced hexagonal patterns

If software development isn't construction, and isn't manufacturing, and isn't "delivery", then what is it? And what does it mean to be "productive" at it? I've long thought of software development as essentially a learning process. It's primary product isn't code or features or executables - those are secondary byproducts. The primary product is KNOWLEDGE. What did we learn about the problem? What did we learn about the technology? What did we learn about the design? What did we learn about the process? What did we learn about each other and how we work together? We get the most meaningful feedback from releasing working software into the world, but we mistake that for the gold and miss the real gold in the feedback we get from it. And when you look at software development that way, it becomes a whole different ball game. The dominant conceptual models of software development coming from systems theory focus on batch sizes, bottlenecks, queues and maximising the "flow" of "value" through the development system. I find this model useful when considering the process of "delivering" software - specifying, writing, testing, reviewing, merging and releasing working software. But it tells me nothing about *learning*. It's a fundamental category error - the real value isn't flowing out through our deployment pipelines, it's flowing back with the feedback from our releases - if we can see the signal in the noise. For that, we turn to Information Theory, which conceptualises learning as the reduction of uncertainty through the acquisition of information. In particular, the concept of "information gain" in the design of experiments: we optimise experiments for maximum learning. Signal-to-noise ratio (SNR) is crucial because feedback only produces information gain to the extent that we can distinguish the signal from the noise. Claude Shannon's channel-capacity theorem gives us a useful analogy. The equation doesn't directly describe human or software learning, but it illustrates the principle: increasing the volume of feedback without improving its signal quality has diminishing value. Sound familiar? Ship one change to the software, and users will tell you what's wrong with it. Ship 100 changes... Every software release is an experiment. I'll repeat that: *an* experiment. We learn much faster when we pose one question at a time. The counterintuitive upshot is that many teams can accelerate learning by shipping *less* stuff, more often. But not *too* often. The world turns at its own pace, and feedback can only come so fast. When we outrun reality we get the same effect as shipping in bigger batches. Some teams would learn faster if they slowed their release cycles down.