When it comes to API development, consistency matters, training pays, and you can't be afraid of a few claws, says an Ancestry.com exec.
Have you ever tried to train a software engineer? It's a bit like bathing a cat -- think explosion, water, claws, fangs, pain.
Well, maybe it's not quite that traumatic, but programmers definitely have strong personalities and can sulk like a cat betrayed if you try to tell them how to do their jobs. Now, strong personalities are good, but they can bring challenges when an organization needs to standardize development -- and APIs are all about consistency.
My company, Ancestry.com, has awesome software engineers, products, and APIs. However, programmers are not usually trained as API designers. Furthermore, as companies build their API programs using multiple teams, APIs tend develop their own personalities and become radically different from one another. That's a problem.
Fortunately, it doesn't have to be that way. Companies can get consistency in their APIs through engineer training. If all developers hew to one set of guidelines and standards, all your APIs will feel similar.
"What's the benefit of that?" you might ask. "Why should I take the trouble to make similar APIs throughout the company? That's a lot of work, time, and coordination."
That's it -- time to market (OK, that's not the entire answer, but I'll get to the rest shortly). It saves the company time and money when a software engineer doesn't have to learn something radically different each time he or she consumes a new API. And if a team needs to aggregate several APIs, imagine how frustrating it would be to learn each API when each one behaves uniquely.
When an API is well designed and consistent, development speeds increase, and the business shortens time to market. That's good for the company's bottom line. More importantly, it's good for customers, who get new features sooner and thus become more productive.
What's the other advantage of having API standards across teams and services? Software engineer happiness.
You might be surprised at how miserable it is to wake up day after day and have to work with an ugly API. When the engineer lifts his head off the pillow each morning, he thinks, "Oh, no, I have to use that API again." It's enough to make him want to bathe his cat instead of going to work. Worse, a miserable developer is not a productive developer, and he is more likely to jump ship.
All in all, good development standards are a big deal -- they save time and money and make for happier engineers.
At Ancestry.com, we made the commitment to spend time and money on an internal development Platform -- with a capital P -- to produce standardized, consistent, and documented internal APIs. We're proud of this effort, and we want feedback. We're also willing to share how we "declawed" this particular problem in hopes it can help others.
Platform = shortened time to market The first order of business when building a Platform is to create the following helps and tools:
A platform portal wiki
A technical knowledgebase
A documentation hub
Posters and newsletters
API design training
First, we created an internal portal, so developers could find all the goodies available to them. This portal is like a wormhole to nirvana. At Ancestry.com, you just type "Platform/" in your browser, and this page magically appears.
From this portal, you can teleport to other dimensions, such as our development standards, a "Getting Started" page, documentation, and more.
Second, we needed simple, consistent development standards to guide our efforts. To be consistent, we needed overarching guidelines such as URL patterns and collection naming.
Harold Madsen directs the APIs at Ancestry.com, the world's largest online family history resource, with the mission to help everyone discover, preserve, and share their family histories. He has more than 20 years of experience in engineering and management and thrives on ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.