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.

In essence, I’m all about the ‘local optima’ - small, iterative changes that ripple out into bigger results in the global picture

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.