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.
Well, I think it absolutely depends. If the method you have already used has good execution time, is (mostly) free of bugs, and works just how you want, then there is no need to write a new way of doing this task. Especially if you are programming for money, or for a company.
However, if you are wanting to learn some new features of a programming language, or simply a different way of doing things, completely for you personal interest, why not?
In a company like Toyota, saving time and money is of utmost importance. However, your personal time has whatever importance you assign to it. If learning a new method of doing something is good for your bottom line then do it. If your bottom line is to learn as much as possible, then this is probably the right thing to do. If, on the other hand, your bottom line is to get as many projects done as fast as possible then it is not.
However, trying a different method could still be useful, even if your bottom line is to save time and money; because, by doing something you've already done with a different methodology may introduce ideas to you that could potentially save you time (and time is money) in the long run.
So I'd pretty much say, if redoing something in a completely different way is what you want to do, then just do it.
This appears to be a duplicate submission of [Never do anything until you ready to use it, in software too? Toyota principle