← kevin.md

đŸ§© Venus Has No Golf Courses

· 3 min read · software-engineeringapi-designopinion

I’ve been reverse-engineering the Topgolf mobile app’s API—pulling my shot data, ball speeds, that kind of thing—and I found something that cracked me up.

Top of the backswing at a Topgolf bay--the data this swing generates is what I was digging through when I found the typo

One of the fields in their API response is venusMemberId.

Venus. Like the planet.

They meant venue. As in, the Topgolf venue you’re a member of. But somewhere along the way, someone typed venus instead of venue, it passed code review (or there was no code review), it shipped, and now it’s in production. Responding to every mobile client. Parsed by every version of their app sitting on millions of phones.

{
  "venusMemberId": "abc-123-def",
  "firstName": "Kevin",
  ...
}

But the funny thing is—they can never fix it.

The Typo Trap

Once a field name ships in an API response that mobile clients parse, it’s frozen. Not temporarily—permanently. Or at least, for as long as you care about not breaking older app versions.

Think about it. Right now there are Topgolf apps on people’s phones that have a line of code like member.venusMemberId or json["venusMemberId"]. Those apps were compiled and shipped months or years ago. The users haven’t updated. If Topgolf’s backend team “fixes” the field name to venueMemberId tomorrow, every one of those older clients silently breaks. The member ID comes back as null, and suddenly nobody can check in at their local Topgolf.

So instead, every new version of the app—for the foreseeable future—has to keep parsing venusMemberId. The typo is load-bearing.

You could do a migration where you send both field names for a transition period, then deprecate the old one after enough users have updated. But that’s a lot of coordination and risk for
 fixing a typo. Nobody’s going to prioritize that. It’ll sit there forever, and every new engineer who joins the team will squint at it and ask “why does this say Venus?” and someone will sigh and explain.

This Happens All the Time

The most famous example is the HTTP Referer header.[1] It should be Referrer—two r’s—but someone misspelled it in the original HTTP spec in 1996, and now every browser, every web server, every proxy, every CDN on the planet sends and expects Referer with one r. Thirty years of infrastructure built on a typo.

Or look at JavaScript’s charCodeAt—camelCased inconsistently but baked in forever. Or the PATCH method debates, or that time Unix shipped creat() instead of create() because Ken Thompson was saving keystrokes.[2]

APIs are like concrete. Liquid and shapeable for a brief window, then permanently set. The moment a client depends on a field name, that name stops being a label and starts being a contract. And contracts don’t care about spelling.

The Lesson (If There Is One)

I don’t think the lesson is “proofread your field names”—though sure, do that. The real lesson is that API design decisions are disproportionately permanent compared to almost everything else in software. You can refactor your backend, rewrite your database layer, swap out your entire tech stack. But the shape of your API responses? Those are basically tattoos.

It’s a weird inversion. The stuff that feels trivial at the time—what do we name this field?—turns out to be the hardest thing to change later. And the stuff that feels monumental—which database do we use, what language do we write the backend in—is actually replaceable.

I’m building an app that pulls data from this API, which means I now have venusMemberId in my codebase too. The typo has escaped Topgolf’s servers and is replicating in the wild. Somewhere, a backend engineer who left the company three jobs ago has no idea they’ve permanently named a variable after the second planet from the sun.

Update, July 2026: that app shipped. It’s called BaySpeed—free on the App Store—and it computes the ball speed Topgolf doesn’t give you by running the physics backwards from your game history. I wrote about how that works in Where the Ball Stopped.

Citations

[1] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0, Section 10.13: Referer — IETF, 1996 ↩

[2] The creat [sic] Unix System Call — Pedal Driven Programming, 2024 ↩

Related posts
Projects · GitHub · 𝕏 · Instagram · TikTok · Spotify · LinkedIn · Buy me a coffee