Perhaps the most famous anecdote about Henry Ford is how he managed to eliminate an entire manufacturing process while getting his suppliers to unwittingly supply him with car components for free. Ford's receiving department was throwing away a lot of material whenever shipping crates were discarded, perfectly good pre-milled wood that Ford could possibly reuse as the floorboards in his cars and trucks. Unfortunately he was unable reuse it because the shipping crates were too irregular and contained too many imperfections. So Ford solved this problem by adding some requirements to his contracts with suppliers. Quoting here from a 1983 paper on the subject of improving shipbuilding productivity regarding one such supplier:

The supplier was delighted to receive the parts order, but was greatly annoyed that the order came specifying precisely how the parts were to be crated for shipment. He was required to use a specific type and thickness plywood, a certain size on each side and oddly had to have rectangular slots at very precise locations on one side. The shipping crates had to be bolted together at specified points with a specific size and type bolt. None of this made any sense to the supplier. What the supplier did not know, of course, was that upon arrival at the Ford plant the crates would be carefully disassembled after the ordered parts were removed and the crate sides became the exact fit floorboards for Mr. Ford's cars, even to the use of the shipping bolts to hold them down.That is productivity. Henry Ford had it and in many areas of this country we still do. Oh, yes, the rectangular slots -- they were cutouts for the brake and the clutch.

Ford's suppliers were by default nonchalant about the construction of shipping crates because such crates were never expected to meet Ford's manufacturing needs. Furthermore Ford's suppliers could not possibly have known how to send Ford more useful crates even if they had wanted to, because they didn't know how to build crates that would be usable in Ford's cars. It would have been impractical for Ford to try to remanufacture the wide variety of incoming crates he received. Instead, by merely issuing a specification and required his suppliers to adhere it, the impractical became not only possible but superbly efficient.

The same concept is widely used today in many industries. Take credit and debit cards for example. Imagine the expense that retailers and financial infrastructure firms would have to undertake if credit and debit cards did not conform to a single well-defined interface. Every store would need a separate terminal for every type of card. The self-pay gas pump would probably be impossibly expensive to manufacture. Imagine the businesses that would not even exist today because of the impracticality of using a different encoding for every type of card.

In software parlance we would say that Ford and the credit card industry created interfaces. An interface is a common specification to which multiple pieces of software may conform. If a piece of software implements an interface, then we know something about how to interact with it.We know that that software provides us with certain capabilities and that it has some specific "handles" by which we can manipulate it. It's sort of like all the cars you've ever driven - you know pretty much what the steering wheel does in each of them.

Interfaces can save you enormous amounts of development cost. Suppose we are writing a program or web site that must interact with a human user. Such a program or web site will:

• Display information to the user on a screen, with variations:
  • Different screens will display different data.
  • Different screens appear within different contexts.
    
    
• Write data to the database, with variations:
  • Different data goes to different database tables.
  • You might be adding, modifying, or deleting data in different situations.

And so on. A typical app is doing only a relatively few things, but it's doing them with lots of variations. A poorly written app has separate code performing each of these variations. In a well-written app, the common portions of these operations are performed by a single piece of code. This may not sound all that impressive, but the use of interfaces produces fantastic cost differences in code creation and maintenance.

Say for example that we have twenty different database tables that need data written into them. Each of these tables contains mostly different data, but there are some common components in all tables, so we may be able to share code that performs the following operations:

• transaction management (ensuring that data is written in an all-or-nothing fashion)
• audit field updates (who created, updated, deleted the record?)
• record change management (is this record new? has it been modified? do we need to save it?)

And so forth. If the program's internal model of the table data does not implement common interfaces, then we must write separate code to manage this common data in each table. For this app, that's 20 nearly identical copies of code that could easily be managed by one piece of common code.

What happens to your costs when you have 20 nearly identical pieces of code doing nearly the same thing? They go up. Way up. Let us count the ways, in order of approximately increasing expense:

1. You have to pay someone to create each of the 20 copies.
2. You have to pay newer programmers to figure out where all 20 copies are.
3. You have 20 copies of essentially the same algorithm, all of which require separate testing.
4. You have to pay people to try to keep the 20 copies in sync (almost impossible - they will certainly diverge).
5. You have to pay people to figure out how and why the 20 copies are no longer in sync. The cost of this can border on the unbelievable, amounting to many times what it would have cost you to do it properly in the first place.
6. You will ultimately experience a higher failure rate in the field and bear all the costs associated with such failure.

You don't need a degree in computer science to see the cost benefit of using interfaces. But of course if your management plan doesn't contain some significant assurance that your programmers are creating and using interfaces, you're almost certainly not going to get them.