I was out running.. listening to a podcast about Toyota.. anyway.
This principle I think does not come to use in the software projects. (maybe project management). The art is still to young. We don't know what we are doing, at the moment. But eventually, we will.
Or, do some one see how to use this core principle?
Ok, here is the podcast. I think it is interesting
I would suggest a small modification, if the method has been proven to work properly (performance/maintenance/security/etc.), THEN use that every time.
The trick is the "proven to work", and also the "properly".
So basically, unless there is a problem with the current method, don't change it for the sake of change. (Note that a method that works provably better, in actuality highlights that the other method has a problem, notably does not work as well).
Particularly in our field it is especially applicable, because of the productivity/scalability gains you get when most code is built the same way. E.g. maintenance, developer training, etc.
In other, more familiar words from the famed philosopher:
If it ain't broke, don't fix it.