Programming Interfaces: Introduction

This article is part 1 of 1 in the series Programming Interfaces
  1. Programming Interfaces: Introduction

A few years ago, I was in charge of enhancing and maintaining a collection of code libraries in a company that, given that it was involved in “internetsy” stuff, actually had a fairly large development department of about 120 programmers or so. The code I was working on formed the basis for several other libraries, which formed the basis for other libraries, which were eventually used by the web developers.

This sort of dependency chain is not uncommon in larger companies, but if not managed very carefully, can prove to be very fragile, as small errors in the most basic of components can propagate to most software packages at the end of the chain1.

It came as something of a surprise to me, therefore, that the company had instituted policies regarding such changes only around the time I started working there — and that most programmers I’ve met at this or other companies had only a vague idea of what the pitfalls in any such approach might be.

In retrospect, this is exactly the sort of topic outside the scope of formal education, where you might get to know how to write and design code, but not how to manage it’s life cycle. It’s precisely that gap in education that leads to over a hundred software developers stumbling in the dark about how to avoid affecting other developers with changes they make.

I’m starting this series to provide an introduction into the whole topic.

Note that because this is intended as an introduction2, I’ll be glossing over a few of the lower-level details. I will provide links to further literature in those instances, though.

Defining the Problem

Suppose Alice and Bob both work on different parts of the same software. Alice, who is a cryptography expert, is working on an authentication & authorization module. Bob regularly needs to use some of the functionality Alice’s module provides, because he writes code managing user profiles and some of the profile data is highly sensitive, so may only be viewed by users with the proper authorization.

If Alice makes any change to her module that in some way impacts Bob’s work3, even if it’s to fix a critical security hole, Bob must interrupt his own work schedule to adapt his part of the code to reflect Alice’s changes. But Bob may not be the only user of Alice’s module, so any number of other developers may be affected by Alice’s bug fix.

Let’s assume that Bob’s profile managing code is also packaged as a module, which in turn Carol uses in her code that can generate anonymized statistics of various aspects of the user base — such as their age groups, percentage of female versus male users, etc. Carol’s statistics module us used by Dave’s code, which combines these statistics with profile data gathered from Bob’s module, to figure out what advertisements to show in the application’s user interface.

It may be that Bob can adapt to changes in Alice’s code touching only code internal to his own module — but what if that’s not the case, and he is forced to adapt the interface of his own module in turn? In the above scenario, he would affect both Carol and Dave directly — I think you can see where this might lead.

  1. The dependencies form more of a tree in structure, sometimes even a full-blown graph — but for some reason you speak of dependency chains. []
  2. And, I have to admit, to save me some effort. []
  3. We’ll explore later what type of changes do or do not affect Bob. []