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!

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.

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.

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.

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.