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
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
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
- 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:
- You have to pay someone to create each of the 20 copies.
- You have to pay newer programmers to figure out where all 20 copies are.
- You have 20 copies of essentially the same algorithm, all of which
require separate testing.
- You have to pay people to try to keep the 20 copies in sync (almost
impossible - they will certainly diverge).
- 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.
- 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.