![]() A later decision might highlight the need for consistent performance, cutting our options even more, until we’re to the point where we can choose an algorithm. This would cut down the number of algorithm options. ![]() A later decision might highlight that stable sorting is important. For example, we might decide early on that we need sorting. In each of these cases, we spend time identifying and exploring the alternatives, then strive for a clear, succinct way to present the tradeoffs involved. See the wikipedia article on sorting algorithms for many more algorithms and a fuller discussion. (See The Toyota Product Development System for more.) That’s inspired me to produce the following diagrams. In lean product development, they use tradeoff curves to record their findings. For example, should we use C++, Java, or C#? Should we use an object database or a relational database? Quicksort or insertion sort or radix sort or …? One approach is to identify several alternatives, and spend energy to spike and/or analyze the choices. We’ll look at three ways that software can use a set-based approach. explore many possible designs at the same time and.defer decisions until the “last responsible moment,” when we have the best information.Why might we want to take the set-based approach? Because it lets us: Instead of moving to a solution right away, it starts with options open, then narrows in on a solution. But the point solution is in effect treated as “the right answer.” If we find out it’s not right, we move to a different point.Ī set-based approach takes a different path. In real design, there’s more feedback than in the first game above, of course. The point-based approach proposes a solution, and then iterates by revising to a different point. Instead, let’s use a “set-based” approach: ![]() ![]() Is it animal, vegetable or mineral? Animal. You probably know the game of 20 Questions. You can also see the Poppendiecks’ Implementing Lean Software Development for more on this idea. Reading the book The Toyota Product Development System has me considering these notions again. They see the approach as set-based because it’s built around the idea of finding a solution as the intersection of a set of feasible choices, and it’s concurrent because teams are trying to work “all at once,” not in a sequential, hand-off style. People trying to describe Toyota’s product development process seem to have settled on “set-based concurrent engineering” as a term for one key part. This lets several groups work at the same time, as they converge on a solution. One of the ideas in lean product development is the notion of set-based concurrent engineering: considering a solution as the intersection of a number of feasible parts, rather than iterating on a bunch of individual “point-based” solutions. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |