Why is it that hardware developers benefit from component reuse and software developers do not?
Jack Greenfield recently authored an article on MSDN called “The Case for Software Factories” that I encourage you to read. While I don’t disagree with this article or it’s sequel, there are some areas that I think deserve elaboration.
In his article, Greenfield distinguishes between economics of scale and of scope. Scale is where you can easily make copies of an existing item, Scope is where you can create custom items by assembly components that you already have. When it comes to scale, software has the edge: just duplicate a CD or post an installation file to a server. When it comes to scope, hardware as the edge.
A chip maker wouldn’t dream of designing a chip using individual transistors. They use libraries of components and advanced design software to assemble chips from the simplest ASIC to the largest microprocessor.
Why don’t we do this with software? What do hardware engineers do that we don’t?

Ultimately, it comes down to two things:

• Hardware components have their behavior specified in extraordinary detail. You can predict with great accuracy what even a complex hardware component will do in a system. Microprocessors, for example, come with documentation books that cover every aspect of the chip’s behavior from commands, to electrical characteristics, to the precise timing of signals.
• Hardware developers use sophisticated tools to build systems from components, whether designing a chip from predesigned elements, to building systems using commercial or custom components.

In software we have primitive versions of both. There is a third party component industry (that I’ve been a part of for years with my company Desaware www.desaware.com), but the industry is tiny compared to the overall software market (I discuss this further in my article “Impact of Source Code Availability on the Economics of Using Third Party Components” )

The Heart Of The Problem

The fundamental reason that hardware developers are ahead of software developers in reuse is this: coding is cheap.
Intellectually, we know that software is expensive to develop. We know that coding is a very small part of the total lifecycle cost of software. But when we look at a software component, we still tend to think we can do ourselves cheaper rather than using something off the shelf. The fact that coding is inexpensive gives us a distorted view of development costs.
If software components were specified and documented with the level of detail common for hardware components, perhaps it would overcome some of the reluctance people have to using components, but the nature of the software market prevents this. The component market is not large enough to justify the investment in documentation, customers do not demand it, and the marketing drive to constantly add features to software drives up the cost of specifying and documenting components even further.
Regarding high level tools, it’s easy to justify the long term investment in developing and deploying such tools. But the key word here is long term. Most companies do not think long term. Time to market and this quarter’s profitability are stronger driving forces.

The Hardware Edge

Why have hardware developers turned to components and invested in high end development tools? Because the economics are compelling both on the long term and on the short term!
The cost to develop an integrated circuit are enormous. Prototyping a chip is time consuming and expensive – you can’t just mock up a chip the way you might mock up a user interface. Actually building a test chip is expensive as well – especially for complex chips. Testing is expensive, often requiring complex hardware and programming.
In short, hardware development is so expensive both in reality and perception that at a certain level of complexity it is not only costly, it’s virtually impossible to do without componentization and use of sophisticated development tools that allow a high level of abstraction. It is this cost that forces hardware developers to buy instead of build components (overcoming “not invented here” syndrome). It is this cost that overcomes the temptation to build something because it’s fun – you just can’t rationalize the extra development work the way you often can in software.
Curiously enough, even as the low cost of software development prevents us from enjoying the economies of scope (code reuse), the low cost of software reproduction makes piracy a greater problem in software than hardware (though hardware piracy exists as well).

Links:

Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools by Jack Greenfield, et-al. I haven’t read this, but if you like the MSDN article, you’ll probably like this book.
Code Generation in Microsoft .NET by Kathleen Dollard. Practical rather than academic, if you want to try code generation with .NET, start here.
RSS feeds for sites referred to in this item:
Kathleen Dollard’s Blog