DDD Scotland: your API sucks

I’ve had a talk accepted for DDD Scotland, so many thanks to those who voted for me. I’ve got a few tales of APIs (particularly, but not exclusively Web based) that made my life as a developer harder that it should have been. Whether it’s Security, bad versioning, incoherent naming, or JavaScript’s Date object (zero indexed months? Seriously?), there’s a lot of bad decisions made in interfaces for other developers.

I suspect that a few of you have stories of woe with APIs to work with, and I’d be interested to hear any you may wish to share, to make sure that the suggestions I’m presenting are universal, and not just pain points that I’ve had.

So, now’s your chance to get cathartic over those libraries, Web services, OSes and other APIs that have ruined your day. What API makes you wish you’d chosen a career as a baker?

PS remember that developers are your users, and they want your data, or your service, not your API. Strive to make developers forget your interface.

Advertisement

DDD Scotland Voting last chance

Voting for DDD Scotland is open until , I have 4 talks and an open discussion session submitted, but there’s lots of other potential speakers and talks. Looks like a fantastic lineup for the comeback conference, so go vote, and thank the organisers for getting it back.

See you there.

PS. Apologies for the short post, it’s been a crazy busy week for me – I’ll have some more details later, if you missed my tweet.

Good Apple, Bad Apple

Your name’s not down

Apple has been in the news a couple of times recently about security. In one case, there’s a lot of suspicion of their motives and wailing of teeth. In the other, they get lots of support. But both cases are about protecting privacy and security of their users.

Error 53, for which Apple now has a fix, is about how much you can trust the security gatekeeper, and is a similar problem to UEFI secure boot: if you cannot trust the authentication path, you shouldn’t trust the authentication, whether it’s authenticating a user or a software update. So the correct thing to do when you lose trust is to fail safe and ignore the untrusted path until an alternative authorisation is provided, if available.

In the FBI case, the question is whether Apple can provide access to a single phone, knowing that if access can be granted once, why can’t it be granted for any iPhone? Especially when there was an alternative means to retrieve the data, via iCloud, before the investigators tried to break in. A backdoor is a backdoor and has serious repercussions. As the DROWN announcement declares, poor security decisions by the US government about SSL 20 years ago are still causing security problems today.

I’m not Apple’s biggest fan, but I actually support them in both these cases. If something is meant to be secure, then any suspicion of a breach must fail secure. It means legitimate users can’t retrieve their data, but also there’s no way for illegitimate users to get in either. That includes law enforcement because there’s no technical way to distinguish between an illegitimate user and a valid investigator.

Continuously sellable

In the process of selling your house, you’ve got to optimise for cleanliness and tidiness, which is a tweak to my usual habits, where I try to avoid multitasking and chunk similar tasks together. For example, washing all the dishes in one load at the end of the day, rather than 2 or 3 at a time throughout the day.

There’s an ongoing discussion at work about GitFlow vs Continuous Integration. I chose to try GitFlow on the current project to explicitly decouple features-in-progress from the release initiation and completion due to some major release management headaches in a previous project. This involved both trying to unwind features from trunk that were descoped or failed FAT, and trying to manage parallel versions at various stages (development, release preparation, support). The code was not continuously shippable.

This knocked a few traditional Continuous Integration advocates, as there was no longer a single place where all code was integrated, built and tested after every commit. We traded a highly shared, but less stable, state for a distributed set of more stable states where there is lag between completion of development and being shippable because we valued that more.

We optimised for releasable code rather than shared code, for multitasking and chunking rather than continually cleaning.

I like doing things more often to do them better, strengthening the muscles so each time causes less pain, and I accept that feature toggles are an alternative solution that tries to minimise the compromises by inflicting release information throughout the code.

I still don’t know which is the most effective approach long term, but given recent experience, I will tend toward continually shippable rather than continuously integrated code, so that the pain of integration is pushed back into smaller chunks, that in a good world fit inside a developer’s cognitive capacity. Can you convince me otherwise?