Programming by API and its Discontents

I am reasonably happy with how Ben Evans, who seems to have been listed as a spokesperson for the London Java Community, prepared a “Viewpoint” piece about the Google-Oracle dispute for BBC News. He seems to have presented a readable account of just what the two sides of this case were:

The dispute had run for years and relatively late in the day it took a somewhat surprising turn when Oracle tried to claim that the APIs that constitute the Java libraries were protected by copyright. 

The implication was that Google were not legally entitled to produce an implementation of those interfaces. 

This development represented a major escalation of the case. 

If APIs were held to be copyrightable, this would have repercussions across the entire tech industry. 

Many developers were concerned that this decision could lead to a chilling effect on the production of software, opening the door to a torrent of lawsuits - affecting firms of all sizes. 

On the other hand, if APIs are not copyrightable, then this would allow significant freedom for companies to implement clones of existing technologies, without requiring full compatibility. 

This could allow substantial innovation, but also has the risk that technology standards could be undermined. 

The resulting externalities of increased testing costs and compatibility risk would be passed on to firms who want to deploy technology stacks covered by such a decision.

For many years programming for me has been a matter of solving logical or mathematical problems, rather than developing systems, which is why my programming-language-of-choice remains LISP. As a result, however, I have been personally detached from how much what passes for programming these days now depends on APIs. There have always been software libraries to draw upon; and, in my most recent work, I needed “library code” to save me the trouble of writing my own software to parse a MIDI file. However, for the sort of things I had to do, such “library consultation” probably never involved more that 25% of the overall design.

I remember the first signs of that percentage changing. Smalltalk was a powerful language whose power derived from an enormous library. It was sort of the ultimate Swiss Army knife. The assumption tended to be that anything you wanted to do in Smalltalk had already been done. You just had to find it with the Smalltalk Browser and use it.

I think that it would be fair to say that this was the birth of the “API mentality.” Software developers now depend on those APIs for just about everything from implementing Web page designs to searching a database. As a result much (most?) of what counts for software engineering these days amounts to providing the right “glue” to join together the right API code. This is why API stability constitutes the crux of Evans’ analysis.

However, stability is only part of the problem. The usual joke about “Swiss Army knife” thinking it that, whenever you search for the blade you need, you cut yourself on at least one other blade. As important as the API is a clear specification of constraints on acceptable inputs, along with an equally clear specification of what it does with those inputs. My guess is that a lot of defective software involves 50% poorly specified APIs and 50% developers who do not pay sufficient attention to the specifications (under the assumption that they are not reliable anyway). This seems like the best explanation for why, when I tried to cancel a Comcast service appointment, I was informed that the appointment had been scheduled for 71:00 PM!

There has been a lot of talk about the need for more “skilled labor” for software development. I would hypothesize, however, the software development has been subjected to the same kind of deskilling that has made such a mess out of help desk operations. Programming by putting together modular blocks when you do not really know what those blocks do is a dangerous proposition. The result is that we are all at the mercy of complex systems with no one who really understands how the whole thing works … a bit like the current state of operations in the financial sector.