Need someone to lead product management at your software company? I build high-craft software and the teams that build it. I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Stopping Web Services

Freshness Warning
This blog post is over 17 years old. It's possible that the information you read below isn't current and the links no longer work.

Yahoo Photos is going away and Jeremy wonders what they should do about the API.

Reading about the pending closure of the Yahoo! Photos and Yahoo! Auctions (in US, at least) services leads to an interesting question for those of us in the business of providing free APIs to our services.

What’s the right way to decommission a Web Service API?

Clearly we ought to strive to shut things down in such a way that breaks people’s code the least (code that we’ve never seen and can’t influence).

There’s some good suggestions and thoughts in the comments.

This is right up the alley of Versioning Web Services in which I pondered the problems of improving an API while not breaking existing clients.

I’m looking for thoughts on how to version a web services API or really any software that’s delivered as a service. How do you prevent changes from having adverse effects while at the same time providing improvements. Is different API versions at different URLs really best or only way to go?

That post garnered some great comments as well.

This isn’t a new problem—at some point all software has to deal with how to end the support cycle for particular versions. However, with web services the problem is complicated because clients are fixed to the upgrade cycle of the server.

For a data structure or service delivered over the public web to a disparate set of clients, this isn’t possible. I cannot time the upgrade of the server to coincide with an upgrade of the client. In many cases, I don’t even know who the client is. I certainly don’t control them. And even if I knew them all, synchronizing an upgrade would require that I coordinate the upgrade schedules of multiple clients, maintained by multiple people, with varying degrees of interest and need.

Recently Written

Building the Next Big Thing: A Framework for Your Second Product
Nov 19: You need a first product sooner than you think. Here's a framework for helping you identify a winner.
A Framework for Scaling product teams
Oct 9: The people, processes, and systems that make up a product organization change radically as you go through the stages of a company. This framework will guide that scaling.
My Networked Webcam Setup
Sep 25: A writeup of my network-powered conference call camera setup.
Roadmap Outcomes, not Features
Sep 4: Drive success by roadmapping the outcomes you'll create instead of the features you'll deliver.
Different roadmaps for different folks
Sep 2: The key to effective roadmapping? Different views for different needs.
Micromanaging and competence
Jul 2: Providing feedback or instruction can be seen as micromanagement unless you provide context.
My productivity operating system
Jun 24: A framework for super-charging productivity on the things that matter.
Great product managers own the outcomes
May 14: Being a product manager means never having to say, "that's not my job."

Older...

What I'm Reading