Ask any developer what the most boring and frustrating part of programming is and odds are you will hear “testing” come up in the first couple of responses.  While it is rewarding to get through the testing of any code as the final sign of task completion, the process itself can be extremely aggravating and bewildering.  A savvy consulting services shop will allocate just as much time for testing as development and while they often have to defend such an estimate to their clients, that is experience talking not simply a desire to inflate the bill.

The other aspect of testing that makes it very boring is that it is a process that never really ends.  Just because something works correctly today doesn’t mean it will continue working tomorrow.  Not only are their often seemingly harmless code updates that can have undesirable side effects, there are environmental changes that can also have dire consequences.  I’ve seem many scenarios where a change to a router rule or a configuration update would impact entire systems.  The only way to possibly provide assurances that your application is still working as desired is through continuous regression testing. 

Many organizations and developers will simply rely on the ongoing monitoring of real-time activity in lieu of continuous testing but this will often leave holes in a true continuous testing strategy.  However, true continuous regression testing would provide independent verification that the application or system still behaves as originally intended.

This is exactly why automation and testing go so well together to provide a much higher level of assurance.  This has been realized through the many tools available for testing browser-based applications such as Selenium and TestComplete.  At OpusGrid, we this same combination can be just as useful for API providers and consumers.  This is one of the reasons we targeted API testing in the very first release of LinkSpan.  Just as you can record a set of actions in a browser and play them back, LinkSpan allows you to record a specific API call and define a schedule for that to be played back.  Those results can then be captured in a report or used to send alerts.

So if you are custom building your own test system or find yourself frequently testing APIs manually, please take a few minutes to check out our quick walkthrough video to see how Automation and Testing can make your life a little less aggravating.

Day four of Oracle's copyright and patent lawsuit against Google's Android OS brings a lesson in API design and programming that even the judge declares 'confusing.' http://bit.ly/IBHL9N

Ever tried to explain what an API is and does to a loved one, a friend or an investor?  Imagine having to explain what an API is to a jury!  What are your favorite examples of how to explain "What is an API"?

As I read about the Instagram acquisition yesterday, I was just as struck as others at how important it was to Facebook to own the user experience of posting and sharing pictures with their friends and family.  In fact, $1B goes beyond important in most people’s minds.  Facebook does a great job of facilitating picture sharing from a computer, but Instagram had leapfrogged them in the mobile device experience which gave them obvious concern. 

5 million pictures a day are uploaded and shared using Instagram.  The most valuable part of that process is the actual sharing which is done through Facebook, Twitter and Tumblr.  What is really interesting to me is that Instagram saw an opportunity to enhance a single process and was able to turn it into a billion dollar asset.  Notice that I said enhance, not build or invent.  Users could already upload and share the very same photos with the very same people.  The innovation was an application that simply made things easier and more enjoyable for the user.   This is why it only took 12 people 2 years to grow Instagram to 30M+ users.

The key to all of this quick growth was APIs.  Instagram was able to build an application that enhanced the user experience without starting from scratch because of the FB, Twitter, and Tumblr APIs.  Because of these APIs, they only had to build out their own photo repository which is a lot easier than building your own social network.  Just ask Google   

Building from scratch is really hard and risky and its usually unnecessary.  The key to quickly enabling a valuable customer experience is to build on top of what already exists and reaching out to existing users if at all possible.  No next gen application is an island and yesterday we saw more evidence of how crucial APIs have become in enabling the next wave of innovation.  Instagram is just the latest example and certainly not the last.

Last week I saw an introduction to BuddyPress 1.5. BuddyPress is a WordPress plugin for creating a social community. Like WordPress it's really more of a platform, on which others can add value with plug-ins of their own.

BuddyPress hasn't had a good update in a  while, and the 1.5 release is quite an important one as it turns out.

What I found really interesting was that a large focus of this release is making it a "good community member". Meaning, it integrates much more cleanly with WordPress than in the past. It behaves just like other plugins now - in the past, being a close part of WordPress the developers had taken some short cuts… short cuts that made it harder for other developers to work with.

Why is it so important for BuddyPress to be developer friendly?

Because in today's "game" your value is only partly what you provide out of the box. It's also important for others to be able to innovate on your platform.

While BuddyPress behaved badly, developers were reluctant to innovate because it made their lives more difficult. In particular, BuddyPress used to throw all these unnecessary error/debug messages, so when developers had to debug their own code it was a nightmare. Similarly, developers had little confidence in the quality of BuddyPress itself when their experience developing to it was so difficult.

TheRightAPI is a solution to help developers make sure that their API's are supportive of the community of innovators around them. It's a language for setting and delivering on expectations, so that developers on both sides of the API know exactly how things should work, how they are working, and what's needed in the future.

By the way, if your API is not listed on theRightAPI, let us know please.

Last week I saw an introduction to BuddyPress 1.5. BuddyPress is a WordPress plugin for creating a social community. Like WordPress it's really more of a platform, on which others can add value with plug-ins of their own.

BuddyPress hasn't had a good update in a  while, and the 1.5 release is quite an important one as it turns out.

What I found really interesting was that a large focus of this release is making it a "good community member". Meaning, it integrates much more cleanly with WordPress than in the past. It behaves just like other plugins now - in the past, being a close part of WordPress the developers had taken some short cuts… short cuts that made it harder for other developers to work with.

Why is it so important for BuddyPress to be developer friendly?

Because in today's "game" your value is only partly what you provide out of the box. It's also important for others to be able to innovate on your platform.

While BuddyPress behaved badly, developers were reluctant to innovate because it made their lives more difficult. In particular, BuddyPress used to throw all these unnecessary error/debug messages, so when developers had to debug their own code it was a nightmare. Similarly, developers had little confidence in the quality of BuddyPress itself when their experience developing to it was so difficult.

TheRightAPI is a solution to help developers make sure that their API's are supportive of the community of innovators around them. It's a language for setting and delivering on expectations, so that developers on both sides of the API know exactly how things should work, how they are working, and what's needed in the future.

NYC held it's first hackathon last week and I can't help but wonder if this is a model enterprises should copy.

Rachel Sterne, the city's first digital officer talks about making nyc.gov (NYC's main citizen portal) transparent, open, and participatory.

Aren't these goals admirable? Aren't they something enterprises should want to adopt for their employees, and possibly their customers?

There's tons of data hanging around within companies that would help people do their jobs better. Only, it's usually locked up quite tightly. One needs permission, and a "business justification". Often there is a domain guardian protecting their fiefdom, represented by the information the guardian controls.

When I think about city government, I think about people who control rather than collaborate. I think about an organization that is complex seemingly for the sake of being complex. And, I think about tons of information that would make people's lives easier, if only it were available.

I also think about having very little money to spend on little things.

I see a hackathon as a way to get other people to "do the work for you (for fun)", assume the risk of failure, and let you take credit for enabling those who are successful, even if only 1 in 10 is does something that sticks. It is also an opportunity for the government to get in front of a constituency, in a non-threatening venue, and partner with participants. A true opportunity to listen to citizens, with an equal give and take - NYC gives access to the data, the citizen makes something useful with it and contributes it back to the government for all citizens to share.

If NYC can do this, why can't the Fortune 1000?

I read an article yesterday (forgive me, I forget where) that said employees are the least engaged than they've been in decades. Google's pretty extreme in letting people spend 20% of their time on Google related projects outside of their job description. But, why can't companies let people spend 2 days a month? That's 2 hackathon's a month for people to innovate and connect at a whole new level, and companies to be the transparent and participatory environment that we all wish them to be.

With the API craze that started sometime in the last 24 months, it might be easy to forget that API's are not new. Nor are the things we do with them.

There's been a lot of discussion about understanding your API. What's your business model? Who are your users? I know there are some grey hairs (and some blond-highlights) wondering what the commotion is about.

It's all about integration.

And, when it comes to integration you need an API.

I remember building networks that needed multiple network cards. You know, one for each network protocol (remember Novell Netware or Banyan Vines?). Back then, there was plenty of time to figure out the "application integration stuff" because what was happening at lower layers of the OSI model gave developers the time to react.

Then along came Cisco and others, and they consolidated the network. Yeah, there was a time there was something called a BRouter - a router that also bridged traffic.

(Forgive me, I think the heat-induced lethargy is causing me to be a bit nostalgic... reminding me of when I was young enough that the heat didn't slow me down.)

Anwyays, networks were much harder to build. You actually had to know where your users were, keep them as local as possible to the servers and the apps they were using. VPN's crushed that complexity, adding some more of their own.

The good news was, with VPN's any user could be on any network, but access their apps as if they were local. The bad news was that with VPN's any user could be on any network, but access their apps as if they were local.

It was easy to know - if a user called from the 5th floor, you'd go check out the 5th floor network. Now how are you supposed to know where that user is on your network. (Reminds me of the time a customer lost a server - they knew it was down because it stopped responding, but they couldn't find it. It took about 2-3 hours to find it. It was in a closet, which is also why it failed. There wasn't enough ventilation.)

Fast forward a bit more.

Now there are widespread standards all the way up the stack. Take a WSDL and within minutes someone without any knowledge of the target system at all, but with a reasonable development tool could be integrating systems.

Just like with the users in my VPN example... this creates some great opportunity only we've moved up the stack, so instead of talking about users, we're talking about data. Now, the good news (and the bad news) is that data can be anywhere.

What data? Well, any data. Let's say - customer data. Well, what makes up customer data?

Address. Phone number. You know, customer data.

What does it look like? How is it stored (in each an every system you're working with)?

I know what you're thinking... and let me tell you - Yeah, it does matter. And, it can be complicated.

Let me give you an example.

I upgraded to OS X Lion (for my Mac) this week. I went into iTunes, clicked "buy", and Apple asked me to validate my identity before allowing the purchase. It brought up a panel that asked for my credit card info, name, address, and phone number.

Simple, right?

I was on support for 15 minutes, frustrated, when I figured out the solution.

I logged into American Express, looked up my credit card information, and saw that on my American Express account, my apartment was listed simply as #37F, in a separate apartment field.

Now, I happen to know that the USPS standard for writing addresses is to put the apartment number on the first line, no comma separating. Something like '40 Harrison Street APT 37F'.

When I matched what I put into iTunes to what American Express showed on my account profile, bingo-bammo, it went right through.

Are you doing the integration dance? This isn't some leading-edge SMS-map-real-time-mobile-startup. This is Apple and American Express.

What's going on?

They use different data models. Neither particularly adhering to the Post Office's standard. Remember, it's not just Apple and American Express. It's Visa. Discover. And, so on. And, it's Spotify, Google, Amazon and every other service.

So what do you do? I mean, besides make your users hate you?

Manage your API properly. Deal with the trust, visibility AND data issues in a systemic way. API providers and consumers (both internal- and external-consumers) will have the ability to manage your data model, easily map that data model to the API's that make up your virtual integration infrastructure, and manage your user experience in a way consistent with your brand and user-experience goals.

I tend to approach problems by looking at what they're really about. The classic Henry Ford quote about him saying his customers would have asked for faster horses sorta stuff. I think you can have real breakthroughs by solving the core problem. By working deeper than the obvious stuff on the surface.

When it comes to APIs what's really going on? Where's the value? What can we, as technologists do in order to polish the product to really bring the value to the market?

A few years ago I posted something on facebook about what I was doing at work... only to get a private message from a childhood friend in Israel saying he was working on something similar. We had a great (productive!) discussion that saved us both time, and got better results for both our companies. No confidential information was exchanged, but we were able to collaborate around our common interest - in this case, our common interest was as shared childhood.

Just this week, I rooted my android phone, installed a new version of Android and changed the kernel to one that optimizes battery life. I've been buying unlocked phones in Europe for over 10 years just to "play" so I've been tweaking phones for a long time. However, I never could have made these changes to my current phone without the help of the online Android community. I'm just not that technical. However... with that help, I have been able to make my phone more productive to me, and as an aside, I've gotten better call reception and battery life.

What do both these stories tell us?

While there's value in the ease of use that APIs provide to programmers... there's much greater value in bringing together communities of people so that they can leverage each other's experience. If I trip on a bump in the road, it's much better for you to learn from my mistake. And, while there's sometimes value in learning something the hard way... as my stories illustrate collaboration helps us in ways we might not yet realize.

For an API provider to be really successful, it's important to build a community along with the interface.

It's absurd... and I'm shocked by such raw behavior.

Of course, maybe I'm old-fashioned? I've been feeling my age a bit lately, so it could be.

Maybe, I'm just too hard. I've seen a lot. Did you know that I once created a song for an IT department, so that they'd remember how IP multicast worked? Yeah, that was pre-internet. Well, truth-be-told, pre-internet-as-we-know-it.

And, that's the rub.

I know things. I've seen things... NO! Don't ask. I won't tell.

What I will say is, be careful.

When you look under the covers, stick your nose into places... you'll never look at a computer application the same way. Never speak to a customer service person without wondering. Never. Book. An. Airline. Ticket. Online. Without. Wondering.

Have they used a vendor's native API for integration without creating a layer of abstraction to prevent vendor lock-in?!?!

There, I said it.

Best practice numero uno. Number one. ABOVE ALL THINGS.

Don't code to a vendor's API because you're stuck with whatever they decide to do with it. You've got their methods, and methodologies (what I like to call "integration philosophy") baked right into your application. And, if you diverge from that vendor, philosophically or commercially, you're screwed.

This is extra important when you have people in your organization using external API's. Do you even know who they are? That's problem #1. Make sure to build in a gateway layer, or intermediary layer, whatever you want to call it. The important thing is to decouple your consumers from those API's so that you can operate independently from the vendor, their methodologies and their roadmap, and switch more easily between vendors should you need to.

Good luck, and code safely.

My thoughts this morning are on chaos. Complexity.

Integration.

What's it all about?

Integration.

The single biggest challenge with integration?

Choice. And, the rapid pace of change.

I know, pick one.

I can't.

There are too many options.

Reading an article on Bloomberg News this morning about Groupon's IPO this morning, I saw that Groupon has 482 imitators. Groupon launched in November 2008, roughly 30 months ago. That means, since launch, roughly 16 competitors a month have entered the mix. Keep in mind there are about 20-22 work days a month. That's close enough to 1 a day as to be really scary.

How do you make a good choice with so many options. Modern thinking on happiness says we can't. Too many choices are bad for happiness.

I think they're bad for business too.

And, when you combine all that choice with the pace of change you have situation where people can't keep up. It's like drinking from a firehose every day just to stay even. And, for many people this "integration" thing isn't even their full time job.

What do you think happens when people are presented with tons of choice, and a constantly changing landscape?

They don't choose.

That's right. They choose not to make a choice. And that's bad for your business.

Transparency is a market imperative, and of course, we each have our own interests. Some of us want transparent performance, others security. Some want transparency into how underlying algorithms are calculated, some only care about the response. In any case, transparency is "free market lubrication".

When it comes to integration, a highly complex collection of technologies to solve some business purpose, transparency into what's actually happening, and what can be expected to happen in the future, is critical to long-term success of the API market.