A couple articles draw attention to making extremely small changes. Increase the frequency, make steps smaller and lower-risk. Take that to an extreme and enjoy the surprise that it actually works. Kent Beck and Ward Cunningham are not done changing the software world.
Kent Beck on Testing the Boundaries of Collaboration article 
with test && commit || revert (TCR)
Joshua Kerievsky reminisces about Ward Cunningham teaching test-driven development. Ward challenged the students to see which pair could code with the smallest spans of time with tests failing. The winners thought they were cheating by reverting their changes if they couldn't get the tests to pass within one minute. Ward said nope, not cheating. post
Both examples prioritize the development experience of maintaining a tempo—and encouraging a high-frequency tempo—over the code produced each cycle.
Contrast Tempo Interruptions
Seems worth noting that there's a lot more in Kent's article than just a story about test && commit || revert. He takes us on a journey of the long, patient, meandering journey that lead to his willingness to try such a radical practice. And because we know something about the history of the author, we know he has experience much earlier in his career working with Ward on radical innovation in software development. There's a history of challenging dogma and convention.
Also notable in Kent's article is a theme we find in our own project of re-envisioning software development. Extreme programming was born at the beginning of the personal computer revolution. Software built by small teams to run in isolation on small computers. Our world has changed and Facebook, where Kent was working, had grown from 700 developers to 5,000. He was wondering how to coordinate the work of 10,000 developers. And worth noticing that the linux kernel has seen contributions from 15,000 developers.