我当时在跑..听有关丰田的播客..无论如何。

我认为该原则在软件项目中没有使用。 (也许是项目管理)。这项技术还处于年轻阶段。目前，我们不知道我们在做什么。但最终，我们会的。

或者，有人看到如何使用这一核心原则吗？

好的，这是播客。我觉得很有趣

http://itc.conversationsnetwork.org/shows/detail3798.html

解决方案

我建议做一个小的修改，如果该方法已被证明可以正常工作(性能/维护/安全性等)，那么每次都使用它。
诀窍是"经过验证的工作"，也是"正确的"。
因此，基本上，除非当前方法有问题，否则不要为了更改而更改它。 (请注意，实际上一种方法可证明效果更好，这突显了另一种方法有问题，尤其是效果不佳)。

特别是在我们的领域中，它尤其适用，因为大多数代码以相同的方式构建时，我们可以获得生产率/可伸缩性方面的收益。例如。维护，开发人员培训等。

换句话说，著名哲学家更熟悉的话是：

If it ain't broke, don't fix it.

好吧，我认为这绝对取决于。如果我们已经使用的方法具有良好的执行时间，并且(大部分)没有错误，并且可以按我们希望的方式工作，则无需编写新的方法来执行此任务。尤其是当我们为金钱或者公司而编程时。

但是，如果我们想学习某种编程语言的一些新功能，或者只是想一种不同的处理方式，完全是为了个人利益，为什么不呢？

在像丰田这样的公司中，节省时间和金钱至关重要。但是，个人时间具有分配给任何重要性。如果学习一种做某事的新方法对底线有利，那就去做。如果底线是要学习尽可能多的东西，那么这可能是正确的选择。另一方面，如果底线是要尽快完成尽可能多的项目，则不是。

但是，即使底线是节省时间和金钱，尝试使用其他方法仍然有用。因为通过使用不同的方法已经做过的事情，可能会向我们介绍一些想法，从长远来看可能会节省时间(时间就是金钱)。

因此，我想说的是，如果我们想以完全不同的方式重做某事，那就去做吧。