Version Control and Set Based Development
There are a lot of people hacking on the Linux kernel all around the world. And while they mostly work on this or that sub-system, there are a lot of cross-cutting concerns. Not only that t there are any number of people working on cleaning up old kruft, so you’d expect that they would either need to be very well coordinated, or they would have a lot of patch related pain.
But they don’t!
This is the result of the widespread use of a distributed version control system, where every single linux developer can publish their own source tree, and cherry pick patches from anybody else’s source tree. This, when combined with a set of maintainers — who get patches, aprove them and put them in their own trees and then work with Linus to get them moved into the “official tree” — creates a remarkably effective system.
For people who want to transfer ideas from Toyota’s Product Development success into software development distributed revision control is an all important tool. But unless you let go of your fear of duplication of effort, you’ll never see the full value of Bazzar–NG.
The key to Set Based Development as practiced by Toyta and Honday is the ability to break down your product into different components, with various interfaces. Then you develop the various components concurrently, and work on several approaches to each of the components simultaneously. As you move forward toward product release, you have a series of integration events, where the interfaces between components are defined more and more concretely.
Other critical components for making set based development work are:
- clear documentation of the design decisions for the various approaches for each components — even those not used in the final product
- a single technical lead who can focusing the vision for the entire product when selecting from among the various alternatives
If you do set based development right, you will always have a safe bet, and you’ll almost always have one or two experimental pieces that turn out great — even if they don’t turn out to be a good fit for the specific product you are working on right now.
But this only works if you can leverage tools like Bazaar-NG to make sharing patch sets easy, and make branching and merging custom development trees painless. Of course, no tool is going to take away the need to document trade-off curves, or make good technical choices for you or your distribution team. But distributed version control tools should make it easier to have lots of choices, and easy to find the right ones for your project and fit them into your product.