Assembling software: Industrial Style

The origins of lean thinking lie in production and there’s quite a bit of interest in finding parallels between current software development practices and those of manufacturing. The Poppendiecks for instance, frequently quote examples from classic manufacturing companies (Ford, GM, Dell, Toyota) to help understand why agile methods are a very effective approach to software development. Oddly enough they (and many, many others) are hesitant to buy fully into the concept that manufacturing industries and software development have indeed much in common.

Early in their book “Lean Software Development: An Agile Toolkit”, it says:

“However, lean production practices -- specific guidelines on what to do -- cannot be transplanted directly from a manufacturing plant to software development. Many attempts to apply lean production practices to software development have been unsuccessful because generating good software is not a production process; it is a development process.

Development is quite different than production. Think of development as creating a recipe and production as following the recipe. These are very different activities, and they should be carried out with different approaches. Developing a recipe is a learning process involving trial and error. You would not expect an expert chef's first attempt at a new dish to be the last attempt. In fact, the whole idea of developing a recipe is to try many variations on a theme and discover the best dish.

Once a chef has developed a recipe, preparing the dish means following the recipe. This is equivalent to manufacturing, where the objective is to faithfully and repeatedly reproduce a "recipe" with a minimum of variation.”

Well, Tom and Mary, allow me to disagree! The main purpose of the modern assembly line is not to produce masses of the same good “with a minimum of variation”. Actually, for car manufactures this is about as far from the truth as it gets. The Mercedes-Benz assembly lines in Sindelfingen near Stuttgart for example, produce hundreds of thousands of variants of the C-, E- and S-class. There are about 8,000 cockpit variants and 10,000 seat variants for the E-class alone; there are almost certainly no two identical cars rolling of the lines on the same day. What starts of with me (if I were a Man of the Three-Pointed Star) ordering a car at the dealership results in an enormous logistic and organizational effort to get the right components to be available at the right place and at the right time on the assembly line (with suppliers supplying the right parts at the right time to minimize storage costs). Raise your hand if this fits with your idea of a “recipe with a minimum of variation.”

Software engineering lags more than a century in maturity behind manufacturing; it is really more like a cottage industry handcrafting one-of-a-kind solutions than proper engineering. The current practice in component-based software engineering amounts to getting just the individual parts necessary to assemble a single car. Some of these parts are not a perfect fit, and some cutting and filing is needed to make them fit (i.e. adapt them) and some parts are purpose-developed for this one car. And even if a library of elementary, designed-to-fit components is present (‘no cutting and filing required’), these still have to be assembled manually and there’s still a lot of detail to consider in the process.

Compare this to ordering a ready-made car by describing it in abstract, solution-oriented terms, stating only as much as is really needed: “Get me a SLK 55 AMG, shod on 18” wheels, with chromed exterior mirror housings.” And that’s what I would like as a programmer: stating what I want in abstract, solution-oriented terms and have the desired system or component produced in an automated fashion.

If this sounds all to magical, it is really a paradigm for software engineering based on (i) designing implementation components to fit a common architecture, (ii) the configuration knowledge linking abstract requirements to specific constellations of such components, and (iii) implementing this configuration knowledge in an automated fashion. These steps are what happened to car manufacturing as well: the principles of interchangeable parts (Hall, 1826) led to the introduction of the assembly line (Olds in 1901 and refined by Ford in 1913), and automation using industrial robots in the 1980s.

Not convinced yet, let me end with the inevitable referral to Ruby on Rails. It may not be on the level of true manufacture, but here’s too a way of specifying a system (‘family member’) in terms of constructs of a higher level of abstraction (‘has_many’, ‘validates_presence_of’), a set of implementation components (‘ApplicationController’) and generators to tie everything together (‘./script/generate’). And boy does it work. Beautifully. Just imagine what the next step will be like!

Comments (8)

  1. Anurag Shrivastava - Reply

    February 8, 2007 at 1:44 am

    I think minimum of variation means minimum of variation with the products of same specifications. Each variant product should have minimum of variation given the same specifications.

  2. Serge Beaumont - Reply

    February 8, 2007 at 9:08 am

    I don't think your comparison is entirely fair. Yes, there may be many variations, but the basic architecture of the car remains the same. You can have a gazillion different types of wheels, but they all have the same four bolt holes to fix them. It would be better to compare Mercedes production to a system that is configured with a whole bunch of options on the client side. Still lots of work, but it's still the same system. Nowadays there are many programs on Discovery channel where cars and bikes are modded. That's still very much creative, unique work, and is much closer to new product development.

  3. Jonathan Greenwood - Reply

    February 8, 2007 at 11:05 am

    Nice analogy but you are confusing product configuration (assembly line) of a known product with the discovery (software development) of a product.

    Better to compare the stages that lead up to but not including production for example from receiving the conceptual marketing brief, design and development to delivering a mock-up/candidate product. This is the discovery phase in a products lifecycle where different individuals add value along the chain. The production process is an art in itself… Transforming the generic bill of material to a production bill of material and for example maximizing the use of raw materials are just a few of the needles in the haystack. I guess you could compare the manufacturing production process to the deployment of a finalized but configurable software product to a target production landscape.

    With regards to Ruby on Rails, I don’t consider it to be a product configurator but more of a pliable cookie cutter. Yes maybe it does allow rapid construction of web based GUI’s on a database. However we still need to discover what the requirements and domain model is. It could be in that discovery process that we don’t want a web based GUI but instead an application that runs on my iPod. Hmmm… the creative discovery process continues but not sure where that leaves me with my Ruby on Rails tools and frameworks. I might have to switch and use different tools.

    In the Application Package world as opposed to Application Development one sees huge repositories of domain and process models that require configuring rather than software development to match the requirements of the client on solutions that we could now consider as a commodity yet when configured correctly can really help provide Unique Selling Points giving a company a competitive edge. This is nearly comparable with the manufacturing process you alluded to but there is still a “short” discovery phase required to configure.

    Just to finish off. The added value of AP companies such as SAP is that they focus on selling business solutions to common business problems on tried and tested technical infrastructures (Netweaver) that just happens to rival the likes of IBM, BEA, JBoss. They effectively leap frog the pure technical players by delivering immediate business benefit with reduced risk and discovery time. By contrast custom software development on pure infrastructure product stack players brings increased risk in that the configuration of the technical infrastructure coupled with the application typically still needs to be proven in a fashion almost akin to re-inventing the wheel. This is never done in a production environment. In my view and those of Forrester, this approach leads to project failure, dilution of business features and higher costs per feature due to time spent on the infra/materials aspects than delivering business added value.

    Whilst Ruby on Rails might be a fantastic tool and framework. It is just that. It provides no added business value to common business problems. Generally we will need an increased discovery phase to understand how best to use the tool.

  4. Vincent Partington - Reply

    February 8, 2007 at 1:23 pm

    Ron, interesting article although I don\'t really agree. Like Serge says, all Mercedes\' are basically the same, you\'re just configuring them differently.

    The fact that software does not have that feel leads me to think we have not yet discovered the \"principles of interchangeable parts\" for software. If we really had a working component model then we could build software like we were working on an assembly line.

  5. Ron Kersic - Reply

    February 8, 2007 at 9:04 pm

    @Serge, Jonathan, Vincent,

    I guess I shouldn’t have used the automotive examples, as they seem to have lured you into thinking that “all Mercedes’ are basically the same” with variations limited to “a gazillion different types of wheels” and that a manufacturing process is best compared to “the deployment of a finalized but configurable software product.”

    Maybe a more evocative example would have been the Giza pyramid product line. Seriously, I understand that “configuration” evokes very different images from what I tried to get across.

    What I want to convey is the image of manufacturing software out of components in an automated way; which is the way other industries have been producing (mechanical, electronic, …) goods for years. This would require a means of specifying family members, implementation components from which each member can be assembled, and configuration knowledge to map between a specification of a member and a finished member.

    For cars there’s a system for ordering cars, there are components from which cars are assembled, and there is the configuration knowledge of how to assemble a car corresponding to a given order. Much of the car configuration knowledge is embodied in an automated assembly line. Similarly, for software manufacturing, the configuration knowledge is captured in program form (‘generators’, most likely).

    @Jonathan, you’re right to emphasize the distinction between design and development of “a mock-up/candidate product” and the actual production. Indeed, what I’d like to see happen for our industry is not developing on-off’s but developing a product line for the sole purpose of being able to manufacture product members on a (more or less) large scale later on. After all, the cars we buy are the output from the manufacturing process and not the development hacks (with the notable exception of British sports cars where there is no such distinction)!

    The discovery bit you raised is interesting too because it actually happens at two levels. First, you have to discover the requirements for the product line itself after which you have to discover the specification of a product member for a given customer. In the context of Rails, the first act of discovery has been delivered by courtesy of DHH. The second act of discovery isn’t magically resolved and indeed needs to be addressed. Fair enough, as I didn’t pretend this to go away easily.

  6. Serge Beaumont - Reply

    February 9, 2007 at 10:18 am

    Ron, again I must make a remark about your analogy. I studied mechanical engineering and I have some experience in creating actual physical products.

    Like Brooks said in Mythical Man Month, software's infinite flexibility is an advantage and a disadvantage. It's too easy to say that software should be made out of components like in mechanical and electronic engineering.

    First, the laws of physics help a lot in constraining infinite freedom, which in this case is nice.

    Secondly, mechanical components have functions that are much simpler than the variety and complexity of function that software components have to perform. The relatively simpler set of functions mechanical components perform means that reuse is much easier to achieve. How many variations are there really to pushing and pulling stuff? 😛

    On the subject of components I still consider the Catalysis book by Wills and D'Souza to be the best you can find. One crucial point Wills makes is that good components don't come separately. All components should come in component kits. What we can learn from mechanical engineering is that we need to find or create "laws of physics" for software that will help us to converge components into kits.

  7. Ron Kersic - Reply

    February 22, 2007 at 11:39 am

    @serge,

    It’s not an analogy I’m trying to put forth, if only because –as you already mentioned- a software component can be likened to a mechanical component only to a certain extent. Right.

    Would I do want is to be inspired from the attitude in product manufacture in an attempt to advance the state of our industry. Maybe it’s just me but I just cannot be content with our current fate because “it’s too easy to say that software should be made out of components like in mechanical and electronic engineering”. And after all, we are already inspired by a certain car manufacture as far as lean, waste-eliminating practices are concerned!

    There are 31 variations of Toyota Tundra pickup truck (not my sort of car, but it’ll do as an example) that include engines, wheelbases (a significant design characteristic!) and cabs of different sizes. It’s design engineers didn’t simply create the best truck they can; they needed to create the best truck that could be built in a big factory; a truck — or 31 trucks, really — that can be assembled efficiently and systematically. That’s inspirational!

  8. Sander Hoogendoorn - Reply

    October 7, 2007 at 8:32 pm

    Ron, although we agree on a lot of issues in our industry, I'm afraid we will not likely agree on this one. There is no way we will produce 31 variants of the same piece of software. Jonathan is right in his comments on your original entry: this is configuration. And even enterprise package implementation, the piece of our industry that is most similar to configuring products, such as implementing SAP or Microsoft Commerce Server for that matter introduces far more variance than building 31 types of Toyota Thundra. Building full functional business applications is a totally different area, Yes, it helps industrializing most of our work, including code generators, standard software architectures and standard modeling techniques, but there's just much more to it than assembling standard components. Business applications assist organizations in being unique. And having read into Mary and Tom's work, I agree most of my work resembles product development, not product manufacturing. We should not buy in to metapgore of prodcution lines or worse, building houses, because they simply do not match our industry.

Add a Comment