API size, as discussed by Bloch, would essentially be "how
complex it is to
operate this device" (e.g. the car). One way in
which it could be unnecessarily
complex is if you could turn the
tires separately, instead of just using the
steering wheel to
turn them in sync.
Another curse that causes complexity
is "feature creep"; if
your car not only lets you drive from one place to
another, but
also lets you toast bread because someone somewhere thought that
it would be nice, that would be an example of feature creep.
Having five
different types of brakes for different purposes
would be another (in modern
cars I think the ABS brakes do have
different modes of functions, but the API
has been kept simple by
putting all that behind at most one button to toggle
ABS on or
off and making the car intelligent enough to make decisions on
what
is the best way to brake).
The API of a fighter jet is likely to be much
more complex
than that of a car. That is unfortunate, but it also enables much
more fine-grained control and exposes more functionality than the
API of a
car. For a fighter jet, good API design is crucial; you
really want to give the
pilot all relevant information, and only
relevant information. Similarly you
want to give the pilot highly
relevant (to the task of flying it) ways to
control the plane,
yet keep it as simple as possible.
In the space shuttle
Columbia disaster one factor was, in a
sense, API design: The only indication
given to the astronauts
that the shuttle used thrusters to compensate for
structural
damage was an indicator light that was on when the thruster was
used. Because it was one more blinking light in a vast sea of
information,
that information simply got drowned. Was the API
usable? Yes. It could be used
to accomplish all the tasks that
were required. But was it as easy to use as
possible? How should
it be designed? That's API design. [ Reply to This | Parent | # ]
| 
