The the Coder's Code tells us that we should never make code worse. One way to support that idea is to make sure that all your design changes do not affect behavior in any way.
I've believed this in some form or other for a while but, recently, I've made a new friend who has taken it to a whole new level. His name is Eran Pe'er and he owns a the consulting company DevCraft.
Eran believes in a concept that he calls "Customer in the Room!"
It started as a preamble to coaching sessions. He would explain that, in his ideal world, he was always just a few seconds from being able to walk away from the code, satisfied with the work he has done.
Then it became a game he liked to play. Whenever he was coaching a group of people on refactoring, TDD, or design, he warned them that he might shout "Customer in the Room!" and they would have ten seconds to make sure their code was working at least as well as it was before an exercise started.
Over time, he realized that this was more than a game. This was his way of expressing his philosophy of work - a way of making it real for the people he coaches.
I've always worked in very small increments. When we met, I'd say my average cycle was about three or four minutes long. What Eran showed me was that we can make the increments smaller, still; that we should make the increments smaller.
While true continuity is precluded by the digital nature of the medium in which we work, we can settle for approximating contiguity...kind of like how movies aren't really moving. Each movie is just a series of steps so small that it looks like a continuous transformation of photographic data and simulations motion.
We should all strive for the same level of near-flow in our work and keep approaching code continuity.
