makes a few connections I found interesting:1. Framing the agile movement as a response to trauma — I suspect many other things in our industry could be framed that way? 2. Composition naturally leads to iterative process — not sure if that “naturally” there is justified, but certainly an observation to ponder. 3. How collaboration is such an important part of the agile approach although “programming itself is a quasi-solipsistic activity. A programmer requires, strictly speaking, no more collaboration than does a novelist or painter.” 4. “[T]he presence of a feature can only indicate to a user if a goal is possible, behaviour will determine how painful it will be to achieve it.” and “[Behavior] blurs the line between “fixing bugs” and “building features”, and coalesces the two into a unitary process of “sculpting behaviour”. 1. “Even in a world after programmers, there will still be the work of figuring out—albeit no longer in code—just what you want to tell the computer to do for you—how you want it to behave. There are still a lot of decisions to make aside from what framework you write it in, or whether you use NoSQL, or how you lay out the source tree. If you eliminate the decisions that involve getting the artifact to work at all, the remaining decisions are going to involve whether it works better one way than another. Most of these decisions are going to be the result of trial and error, and a sizable chunk of those are going to involve feedback from users.” And he touched a few other things we talked about here before.