In [his response][1] to my post _[Tools and evolution][2]_, 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 changes fail. 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 (to use an eXtreme Programming term) 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._
[1]: http://sabren.com/index.php?p=75
[2]: http://blog.unquiet.net/archives/2005/07/01/tools-and-evolution/
3 Comments
I stole that term from Eli Goldratt, though I know it’s used elsewhere. When he uses the term, it’s an insult.
His point is that people are always trying to optimize their own little piece of the puzzle: their department, their own job, whatever, with the belief that all these little local improvements add up to form global improvements. But most of the time they don’t.
In any company or process there are probably hundreds of places where things could be improved, but only a few actually make a difference to the overall goal. That’s because only a few address the constraint. Your database example is a perfect example of a local optimum. Maybe you shave off half a second, but if the main loop of the program is slow, then the whole program is slow. That main loop is your constraint, and so the only way you can optimize the program as a whole (global optima) is by optimizing the main loop.
I think we’re saying the same thing but I don’t think I made it clear that the label ‘local optima’ is the thing to avoid, not the thing to be all about.
I do agree that making lots of small improvments to the software in a stream vs a huge release is a great idea, it’s just not what local optima are.
Michal,
I think we’re coming at the same point from different angles. When I read your original post, I was concerned that one might come away from it thinking, ‘well, I’ll just make __big__ changes from now on.’
But I think we both might agree that the better solutions aren’t a case of local vs. global optima but rather one of solving the problems that most directly relate to the services rendered. For example, you provide hosting services; a new control panel may be an ancillary benefit of hosting with you, but reliability and quick support are absolutely expected.
Yep. And “directly relate to the services rendered” is basically what global means. You’re improving the service as a whole, not just some small part. A global optimization can still be a very small change. In fact, it’s often much smaller and easier than the possible local optimizations. Small changes can have huge benefits - if you target the right point.
Post a Comment