… incremental change often succeeds where drastic change fails …
In “his response”:http://sabren.com/index.php?p=75 to my post “Tools and evolution”:http://blog.unquiet.net/archives/2005/07/01/to…, Michal writes about local vs. global optimization, how small changes often improve the entire process, and inefficiencies in the larger picture may actually be necessary. It makes a lot of sense and is essentially the same point I was trying to make, though I might not have been clear enough on the important part. Michal hits the nail on the head when he writes (emphasis mine):
It’s not that I couldn’t have done that before, or done it with those other tools, but for whatever reason, the […] approach made it easy for me to change my behavior.
He uses a Palm to track his food intake and his workouts for the day; had I been willing to develop and end-to-end solution like that, I’m sure that the application I was working on would have been incredibly useful. At the time, however, I had different objectives in mind for the workout tracking software and developing for the Palm wasn’t among them. However, for people who own Palm PDAs, such a solution could have clinched a successful behavior change. Why? Because the changes required by a move from paper tracking to Palm tracking are minimal enough compared to the benefits to encourage the adoption of the new method.
That’s the main point of my last post. Michal noted that software that does not change behavior has no value. I wanted to point out that software that forces change in behavior faces challenges to successful adoption.
That’s another reason incremental change often succeeds where drastic change fails. An iterative route of process change
- minimizes barrier to entry to new methods,
- allows for feedback and ‘tweaking’, and
- tends to optimize for practice rather than theory.
(Believe me, I’ve been caught optimizing algorithms for theoretical speedups before, wasting valuable time trying to shave _milli_seconds off a rarely-used database query)
In essence, I’m all about the local optima – small, iterative changes that ripple out into bigger results in the global picture. In traditional software release cycles, the focus, I think, is on major revision for each major release — that’s what drives the sales: improvements and new features. I’d rather just see continuous improvement and time-based licenses.
I like Michal’s new philosophy for running Cornerhost; I believe it’s much more agile and nimble. When you have a functional solution, you can improve over time instead of rolling out large batches of changes.
Believe me, I’d thank anyone who developed that way – I’ve relearned enough software paradigms already, thank you!
And as for your question, Michal: undoubtedly it would have helped some people lose weight and keep it off; the act of tracking progress is very powerful. However, I came to realize that I didn’t need this myself, that the application’s benefits to me were not sufficiently great to outweigh the extra work, and that it didn’t really change behavior so much as change the locus of the behavior.