APIs and the art of code sharing

A long-standing guiding principle in my field is something we like to call DRY, or Don’t Repeat Yourself. What’s the opposite of DRY? It’s WET, short for Write Everything Twice. Spoiler alert: As a software developer, you don’t want your code to be on the humid end of the scale.

DRY means not reproducing software patterns. The belief is this: If a line of code is repeated within a system, and then part of it has to be changed—for example, a button on a web page needs to change colors from black to green—you may have to update all the repeated lines of code for your green button to appear on the page. Conversely, if every line of code is unique and serves its own purpose, you won’t waste time making multiple updates to see one element change.

How does this tie into trade credit insurance? It has to do with questioning old processes, sharing knowledge and, well, crêpes.

At Euler Hermes, our job is making credit insurance easy and pain-free for our clients. And as the Technical Lead, my job is developing the software to support them. So, when we recently discovered that the deployment of our IT products was stalled by duplicate processes, we launched a simplification and code sharing project. Based on the DRY principle, our solution has saved us huge amounts of time and has led to increased productivity across our business.

I’m based in Euler Hermes’ headquarters in Paris, so I’ll use that cultural backdrop to explain what we do through a concept that’s dear to my heart: French cuisine. Say you want to cook a batch of delicious crêpes. First, you need to prepare the batter. If you’re making crêpes for five people, a standard batch is probably enough. But if you have 500 mouths to feed, you’ll need a lot more. Problem is, they don’t want all the crêpes at the same time, and your frying pan isn’t big enough. To avoid measuring out the same ingredients 100 times, you make one big bowl of batter, then cook it in smaller batches. This way it’s easier for you, and your guests can enjoy fresh crêpes all day.

When Euler Hermes’ IT team builds new software, we work with this concept in mind.

A software project at Euler Hermes starts like this: instead of coding it from scratch, we take our standardized base—or batter, if you will—and add code to it according to the specific business need.

This has been particularly useful for Euler Hermes’ Generic Services API (GSA) team, which I’m part of. Our Application Programming Interfaces, or APIs, are basically the screen you’ll use online to lodge an insurance claim, for example. We discovered basic code that’s needed for most of our APIs, then developed a big batch of standard API bases to share in the cloud. Now, when starting a new project, we can copy and paste a base and very quickly kickstart any type of project.

This change has shaved significant time off our deployment time. Whereas kickstarting a project could take up to a week in the past, it now takes us less than an hour!

You can’t underestimate the value of stepping back and scrutinizing why you’re doing things a certain way. At the end of the day, Euler Hermes’ mission is to help its clients get efficient help, and it makes no sense for the processes behind the scenes to be overly complicated.

I’m lucky to work for a company that sees the value of innovation in IT, but all companies should think about how to optimise its processes across the business. And the key to doing that is through sharing skills and experiences, and questioning the status quo. Otherwise, you’re basically just making 100 batches of pancake batter every day.