Building with Atoms, Building with Bits
Blast From the Past, part 1:
Long ago, I learned a trick: “Whenever you find yourself telling the same story for the third time, write it down and put a permalink on it.” That’s been the organizing principle behind most of my blogging, and one (of many) nice things about recently joining Fractal Technology Labs has been meeting tons of great new people and swapping stories with them. Since many of those stories happen to be written down, it’s been an occasion to revisit old ideas and old writings. While some didn’t age well, but others have prompted rich, rewarding conversations and new ideas. In that spirit, I’m going to try an experiment: disinterring a few old posts, and re-posting them here on the Fractal blog, and seeing if we don’t all find some new conversations to have and make some new stories together.
Originally posted on Posted on 23 September, 2016 on jonathanpberger’s blog.
Engineering is an old discipline.
Building with Atoms
The difference between building for digital and traditional modes of building is the difference between atoms and bits. For traditional engineers and designers who build with atoms, planning is often orders of magnitude less costly than building. Imagine what it takes to build a bridge or a stealth bomber. With these economics, it makes sense to plan first, and it’s crucial to get it right the first time. Only when planning is complete does it make sense to start building. These separate, distinct, serial phases are the heart of what agile software development calls “Waterfall”. Specialization is rewarded, so coordination among specialist groups (planners, builders, etc.) is crucial to minimizing idle time, so that hand-offs can occur in an orderly manner. In this world, predictability of timing and estimation is paramount.
Building with Bits
The digital world is different: the cost of planning and the cost of building is (roughly) the same — it’s certainly the same order-of-magnitude. Into this new world come new economies. Now that the cost of planning is as low as the cost of building, the imperative to Get It Right The First Time (Or Else!) disappears. Now, the important thing is getting it — something, anything — out into the world. Instead of having to model and predict whether you got it right, just get it out there and let the world tell you whether it’s good enough, and how to improve it. This is the fundamental change that makes agile software development possible, and leads to the great emphasis on experimentation, testing, and rapid iteration. In the old world we optimized for predictability. In this new world, we optimize to lower the cost-of-change.
How to build anything
So what does this mean? Agile practitioners regularly disparage “waterfall” but it’s not as if traditional, Gantt-chart style planning is wrong or bad. (It’s responsible for the vast majority of planning and building — EVER.) Rather, Waterfall and Agile methods ought to be regarded as two different tools, optimal for different tasks.
Need to build in a domain where planning is much cheaper than building? Measure twice, cut once — waterfall is probably the right way to go. That doesn’t mean you can’t benefit from reducing the cost of change when possible, but it does mean that predictability ought to be prioritized over optimizing cost-of-change.
Building in a domain where planning and building cost about the same? Agile methodologies (which optimize for low cost of change) will give you a significant advantage.
