article development led by
Bad application programming interfaces
plague software engineering. How do we
get things right?
BY michi henning
After more thAn
25 years as a software engineer,
I still find myself underestimating the time it
takes to complete a particular programming task.
Sometimes, the resulting schedule slip is caused
by my own shortcomings: as I dig into a problem, I
simply discover it is a lot more difficult than I initially
thought, so the problem takes longer to solve—such
is life as a programmer. Just as often I know exactly
what I want to achieve and how to achieve it, but it
still takes far longer than anticipated. When that
happens, it is usually because I am struggling with
an application programming interface
(API) that seems to do its level best to
throw rocks in my path and make my
life difficult. What I find telling is that,
even after 25 years of progress in software engineering, this still happens.
Worse, recent APIs implemented in
modern programming languages
make the same mistakes as their
20-year-old counterparts written in C.
There seems to be something elusive
about API design that, despite years of
progress, we have yet to master.
Good APIs are hard. We all recognize
a good API when we get to use one.
Good APIs are a joy to use. They work
without friction and almost disappear