The Value of APIs


To be clear, we’ll be using the Wikipedia definition of an Application Programming Interface (API) which “is a set of routines, protocols, and tools for building software applications.”

I have been programming long enough to have written Databus, COBOL, all kinds of assembly code, C++, and even wrote my own hard error handler using interrupt 0x24—which essentially is a hard error exception handler—and  my own direct video buffering code, direct text-based graphics GUIs—I think EGA video may still be somewhere around segment B800. This level of programming is painful, time consuming, and this is why ASCII-based GUIs and 80s software sucked. You don’t have time to learn this stuff or even read Ralf Brown and James Kyle’s 1,210 pages of PC Interrupts. This knowledge was useful when apps were simple.

Nowadays, there are so many technologies that very few people have time to tackle, let alone master them all—JavaScript, jQuery, CSS, HTML, XML, T-SQL, MySQL, PL-SQL, LINQ, XSLT XPath, Angular, Node, make it stop. It’s time to stop thinking of software development as less about programming and more about assembling routines, protocols, and tools.

The only thing that should be written from scratch is the comparatively few bits of code that distinctly provide your enterprise with a competitive business advantage and that only if that code doesn’t exist already. Everything else must be some kind of pre-existing routine, protocol, or tool. (Tool can encompass small or large components, such as Microsoft Dynamics or SAP.)

Your job is choosing your API poison well.

Rolling Your Own

The only thing you should be rolling is your own cigarettes. You don’t have time to write everything or almost anything from scratch. You don’t have the time and you don’t have the expertise. If your pointy-headed manager—I am sensing a theme here on the manager thing—won’t let you buy the APIs you need or use great open-sourced tools, your boss is a chucklehead who is driving your company or project at speed to a nasty cliff. Pull the rip-chord, bail, jump ship, ditch.

Don’t get me wrong; I love to roll my own. Writing code is so much fun that, even after three decades, it’s my favorite thing to do, but the only time you should ignore this advice and roll your own is if your business is writing APIs.

Key Business Differentiator

The only code that should be written from scratch is the code that will give your business a distinct, competitive business advantage. The reason you write this code is because you have to because it doesn’t exist in the formulation that is a key differentiator.

The caveat here is if you can repurpose code from one domain—say banking—and re-purpose it to social networking, say a dating site, you shouldn’t write this code, either.

The critical message here is “key differentiator.” Only the code that helps you win is code you have time to write. Everything else should be assembled, aggregated, composed from other bits.

There is no time to do analysis, design, coding, unit testing, debugging, Q&A, or producing useless user guides for non-key differentiators like log-in screens, CRUD editing screens, maintenance screens, algorithms, goofy whiz-bang JavaScript, or any of that stuff. Redoing all of that stuff every time is the detritus of a failed process. It’s like Catholic guilt—it’s a ton of bricks, put it down. (Okay a little guilt is good; keep your inner freak for special alone time.)

Every time I am on a project and I see requirements documents for login screens, maintenance screens, or almost anything, I want to scream. This is a stupid waste of time. Again, get out. Life is short and, if your employer has a “methodology” with a cutesy acronym, run!


“How do you put out an oil well fire?” You blow it up.

I call this the Red Adair approach to software development. If you don’t know how to build software, you are putting yourself unnecessarily n harm’s way, which could result in serious injury or death,

Now, I will assume you and I have an accord that we will only spend our time on key differentiators. No more wasteful, useless acronymic methodologies, no more systems engineering methodologies. (If you need those, then, by definition, you know not what you are doing.) No more boilerplate dribble-drabble, no more code reviews, guidelines, or boring meetings discussing the formats of dates. Who cares?

To answer my implied question, then, what is my key differentiator? The answer is what is your raison d’ être. Not the BS parts, but how are you going to make a difference in your business. A recent example that sounds pretty good is “Rocket Mortgage” from Quicken Loans. Getting a mortgage is a long, painful, douche-laden process. According to the ad blurb, “push a button, get a loan” sounds pretty good. The general idea is that Quicken figures out who you are, what you earn, and if your good for it and violà! You get a loan. If it works, this is a pretty good differentiator—identify yourself and the computer figures out the rest of the bits.

Another good example could have been the United States Affordable Care Act (ACA) Web site. If you could have typed in your social security number only and the system put together gender, age, income, location, occupation, and general health from existing data and offered you one to three insurance plans that actually saved you money, that would have been awesome. Instead, we got useless government crap.

Change the way you think about software. Define the smallest piece that gives you a competitive advantage, focus on the most complex, risky, valuable bits and focus most of your time and energy on that. Compose everything else from existing bits, everything.

Back to Obama Care (ACA). My competitive business proposition would have been:

given a valid social security number

get all identifying aspects of this person, including health history, income, work

history, occupation, income, and locale


provide three insurance plans that save money and don’t suck


collect premium


That sounds kind of simple, right? Wrong. That is very hard, very complex, and very worth doing. They failed. The Web site failed. The business proposition failed, and the insurance companies are bailing. The good news is you don’t have to fail.

What APIs Do I Choose?

Now that we are borrowing existing APIs from anyone we can because, frankly, in the API producer’s domain their knowledge exceeds ours. Which APIs do we choose? We can choose any of them and all of them.

Pick any API you want. Free is good. Open-source is good. Buy is okay, but only if the former two options aren’t available. For a Web site, jQuery and Bootstrap haven’t let me down. The .NET Framework does a great job and a new one, jqWidgets, looks promising. MySql is good. I’ll use SQL Server if I can. I have also been using DevExpress bits for many years now.

The key is that your job is to avoid writing almost everything, so your job is to go out and find APIs that are reliable, supported, that work, and that don’t cause headaches. There are a lot to choose from.

Choosing APIs depends on your technology stack. Your project will be different from mine. The key is quality and a low barrier to entry in terms of cost, learning curve, and the availability of talent. Remember, these aren’t coding considerations at all.

A general rule of thumb is if you don’t know an API, you don’t have time to learn it and deliver at the same time. Learn in between or on someone else’s project. And, for goodness sake, don’t chase APIs. Pick a few that work and ride them to success.


In a nutshell, I didn’t say don’t write any code, don’t test, and don’t plan. Plan what must be planned. Test everything, and you’ll have to create some glue to hold your bits together, but focus your super powers on those parts that will give you a killer result and use APIs as much as you can.

If it feels like boilerplate or déjà vu, skip it. If you are sitting in a meeting and think this is a waste of time, stand up and say so, and then pack up your crap and go somewhere else. (You’ll probably get some help with that.)

More by Author

Must Read