The modern development landscape has changed from when APIs were first being developed. Gone are the days where developers could “develop and forget”, releasing APIs, systems, or applications to the public for consumption and use.

Today, there isn’t really such a thing as a release in the common parlance of yesteryear. When a developer releases a product, they are simply saying it is ready for consumption, not that it is finished.

Enter continual development. The simple fact is this — your API is never fully released. Understanding this simple concept and adjusting your development practices to deal with it cannot only yield impressively capable and extensible APIs, it can also dramatically increase your market performance, revenue, and public conception.

Why Continually Develop?

Never before has humanity been as connected as it is today. In the first decades of mass communication, mail had to be hand delivered astride a horse for their communication — and while this certainly bridged divergent states, towns, and even countries, it was by no means “fast”.

Even with the invention of networking, for a time, the experience was akin to those first days of communication. Bulletin Board Systems had to be “dialed into”, messages downloaded onto local disks and then read and replied to, copies of replies uploaded onto the same systems. For a time, the internet was simply a giant bulletin board hanging on the dorm room wall of humanity.

Things have changed, though. Gone are the days of waiting 24 hours to download a song — now we can stream 4k HD video from halfway across the world, access our email while flying in airliners, and even stream communications from the International Space Station in near-real time.

No longer do we have users in the hundreds accessing network resources — now we have users in the hundreds of thousands. With this huge surge of users and the content that they consume, however, the resources and systems needed to support them have likewise increased. Research analyst company Gartner estimates that by the end of 2016, 6.5 billion “things” will be connected to the internet — all interconnected systems relying on APIs and network resources.

The simple fact is that these users, their systems, and the Internet of Things that they integrate into are some of the most demanding entities in the world, and these demands are always changing. Thus an API developer must change with these demands, adapt to them, and provide these services when they are required. If they are unable to, they lose their competitive edge, and the question is asked — will a user really stick with a service designed for the 2016 internet while using the 2020 internet?

Four Tips for Continual Development

Given this fact, how is an API developer to support continual development? Unfortunately, it’s not as simple as saying “we won’t stop developing” and going about the normal development cycle. A few things need to be kept in mind to effectively support your continual development track and to provide a good service to your developer users.

Let’s look at four tips for continual development that every API provider needs to keep in mind.

1: Limit Your Scope

One of the greatest mistakes an API provider can ever make in traditional development is failing to limit their development scope. Without a clear definition of exactly what your API is for and the range of functions it’s supposed to support, you set yourself up for a world of hurt.

First and foremost, you’re setting your API up for feature creep; when adding too many features to an API or system, the quality and speed of development suffers, as does the service identity. Having a wide development scope also naturally means having a wide range of things to continually develop and update over time.

This increase in development requirement makes the idea of continual development expensive and, in some cases, prohibitively so. Consider developing an API for video encoding. If your API is designed to support basic encoding of maybe two or three file formats, then as time goes on, your API development will just require additional codec support and support for speciality calls from other APIs and systems.

For each required update to the API, the work is magnified two to three times. Contrast this to supporting 10 or 15 file types, and you can see the obvious issues incurred, with each new update having to be spread out over 10 to 15 additional points of functionality.

2: Set a Timeline

Setting a timeline seems strange when we’re talking about continual development. The concept we’re discussing however is not setting a timeline in classic terms — we’re not talking about release schedules, development release dates, and so forth.

Simply put, setting a timeline is establishing a temporary, changeable, but effective milestone program. By setting milestones and establishing a plan to achieve them, not only do you effectively set a schedule of expectations for other teams such as quality assurance, you also naturally deter feature creep — if something isn’t planned, it doesn’t get done.

The best thing about setting a timeline for your development is the added benefit of establishing a pace. Too often, API developers think too much in terms of “sprint”, developing as fast as they can for as large an audience as they can.

This is a bad position to be in. A sprint pace means that processes that must be developed aren’t always given the time that they need, and features may not fully be tested before being implemented.

The best way to pace a timeline, however, is to think “marathon”. Consider your immediate expenses in terms of resources and time, and find out what needs to be developed first. More to the point, consider whether or not your timeline takes into account the necessity of these things that must be done. Looking at timeline holistically, that one pet project might seem much less important when faced with the idea that you’ve planned another more important feature for release right after, and with a more compressed time frame.

3: Future Proof

It’s important to note that when we consider the idea of future proofing, API providers aren’t being asked to know the future. What we mean by future proofing is the idea that, if developed correctly, an API may not have all the functionality that will be required in the future, but won’t be stopped from implementing those functions.

Consider for a moment that previously mentioned theoretical API that handles video encoding. As of the initial development cycle, the API implemented certain quality of life shortcuts for users that made it a very powerful and user friendly tool.

The problem now lies in those shortcuts. The API automatically detects the file type and encodes it given certain settings. For instance, when the file is in 1080p, the API encodes using h.246 to Mpeg.

This sounds great, but there’s a catch – what happens when a better encoding format is released? What happens when h.246 has a new revision? All of these future cases means that the shortcut that automatically attaches a certain filetype to an encoding method is not effective, and definitely not future proofed.

A big example of failure in this realm in the real world is the Y2K crisis in the late 1990’s and early 2000’s. The problem arose from adopting dating conventions for bit conservation, resulting in the year 2000 rolling over in the code base to 1900.

It’s become a common meme that the Y2K issue wasn’t a legitimate issue, but that’s far from true. Entire companies dedicated huge IT staff to fixing code for programs that did not support the proper dating standards. Even then, the problem resulted in some significant problems ranging from incorrect medical test results to false alarms at nuclear generation plants.

Because the developers of various APIs and programs failed to take into account the future proofing of their underlying systems, huge problems launched after the year rolled over.

As an API developer, you can’t read the future — but you can make projections. Ensure the known future issues will be easily rectified, or at the very least, don’t adopt shortcuts if they will make future revisions more difficult.

4: Avoid Dependencies

Dependencies are great tools for API providers wishing to extend the usability of their software. Unfortunately, many API providers and developers don’t use them for extensibility, but instead for basic functionality.

It is very daunting to consider using a pre-formed solution for your mail handling or error reporting systems, but it incurs a cost. When the future comes, and you need a better solution, just how integrated a third party solution is, and how much of your internal code depends on it, will determine how efficiently and effectively you can upgrade the source.

That’s not to say that dependencies should be avoided — more accurately, avoid using dependencies as a crutch, and code failover solutions for when these dependencies fail. In networking, there is a concept called “fail open” — when a security door to a network closet is equipped with a biometric scanner that fails, it fails open rather than continues to stay locked, so that people can get in and out in an emergency.

The same is true here — it’s perfectly fine to use a third party solution, but have a backup plan for when it inevitably fails. For your API, even something as simple as having a feedback codebase with a failover that replies “we’re sorry, feedback servers are not available at this time” when your external feedback client fails is much more effective than returning error after error to your user.

Avoiding API dependencies when at all possible, and implementing backup solutions when not possible, creates an API that does what it must do even when what it depends on is unavailable. This creates a seamless and effective system for all users.

Conclusion

Thankfully, a good deal of the continual API development cycle is not one that is manual, as “continual development” suggests. While changes need to be made for new formats, functionalities, and so forth, successful initial development strategies and the general development culture will lead to ease of adaptation for the future.

Whatever is your situation, never forget — your API is never fully released. Keep that in mind, and use it as a development culture, and success will be easily won, and easily kept.