Programming Interfaces: Introduction

This article is part 1 of 1 in the series Programming Interfaces

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.

Read the rest of this entry »

  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. []