Sold-out Event Kicks Off Developer Outreach at Ticketmaster

As we prepare to roll out a ton of new technology and deliver APIs that developers love this year, we’ve started to engage the developer community to get their feedback on our redesigned developer portal and the updates to our APIs before we launch them.

Last Saturday, we held our very first event in Scottsdale, AZ, to a sold-out audience of enthusiastic geeks. The event helped set the tone for all future engagements with the developer community. It also clearly showed how external developer feedback is critical to the health and stability of a platform and how we need to hold more of them often.


Over 75% of registered participants showed up. The market average of free events like this is about 40%. I think we did well 🙂

The turnout showed how much the community is interested in what we have to offer. Some of the attendees flew in from Virginia, NY, Washington and California. The energy and the feedback we received were far more than I had hoped for.

Also, five API demos were given at the end of the day, which was great to see 🙂

jodymulkey_2016-Jan-16 (1)

The Results

The verbatim we received from developers was overwhelmingly positive with lots of feedback on what we could do better. Here’s some examples of what they said:

The whole platform is very clean and simple. It’s very easy for any developer to jump right into it.
all good…took a few minutes to get oriented to the various parts.
I found myself flipping between the interactive demo and the static documentation a lot. It would be helpful if I didn’t need to do that.
API response docs should be present
So far I can see it is very easy to use, with clean documentation and quick starter.

I’m a biz dev guy…the fact that I can understand any of it makes it pretty impressive from my pov.

The API needs to consistently deal with images for non-events. We also need a way to get a link to an event itself, not its attraction(s). Also, it needs to have a way to identify the base URI for relative URLs.

A few common themes emerged:

  • API bugs
  • Data inconsistencies
  • Documentation completeness
  • Need for tools and SDKs

We gathered detailed feedback throughout the day and the team is currently addressing them. The state and quality of the platform will be a whole lot better by the time we hold our next event in Los Angeles in February (stay tuned).

Open Platform NPS = 65

Overall, our initial Net Promotor Score, or NPS, is 65. This is a pretty high score (Amazon’s is 65) and shows a lot of goodwill from the developer community. Our goal is to keep our NPS above 70. Now that would be amazing! 🙂

Aside from the written feedback, we also asked developers to rate us on various aspects of the platform. Here’s how we fared:


Stay Connected

Follow us on Twitter and subscribe to our Medium Publication to be the first to learn when we launch the developer portal and make our APIs publicly available. Exciting times ahead for the Ticketmaster Open Platform 🙂

Tests and Comic Strips: How Dilbert Explains a Philosophy of Testing

At Ticketmaster, we’re committed to testing. Automated tests improve our stability, helping us sell tickets to more fans and add new features. As a developer, I have an additional motivation to write tests well: tests illustrate the intended behavior of my code. Besides achieving good code coverage, an articulate test quickly teaches another person what my code does. Here are a few cues that I’ve settled on, inspired by comic strips.

Testing speeds things up.


DILBERT © 2015 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Keep it short

Three frames, four lines of dialogue: that’s limited space for pictures and words. Readers will skip over a fifty-line test block with glazed, lizard eyes. Do you want your readers to pay attention? Keep it tight, then.


DILBERT © 2015 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Stay focused

Test one feature at a time.


DILBERT © 2014 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Do you love Game of Thrones? Complex subplots, amirite? Intertwining narratives are fun, but testing many things at once is just confusing. Instead of writing one script that covers all possible cases, I separate each behavior into its own test. One strip, one joke; one test, one case. Isn’t that a Marley song?

Be self-contained

The Boss wants data-driven product releases.


DILBERT © 1994 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Do you recognize Dilbert and the Boss? Of course! Did you forget what happened before this strip from 1994? Maybe a fanboy remembers, but everything you need to know to get the joke is in these frames. I describe this as episodic style. The tests form a series of short narratives with familiar actors, but the events of one test do not impact the outcome of another. When tests rely on the same data, I generate fresh objects before each test. Tweaking the data for a particular test won’t pollute the tests that come after it, and my readers won’t need to track state as they scroll down the page.

Clear narrative

Have you noticed the similarity between Given-When-Then stanzas and the Arrange-Act-Assert pattern? These templates both resemble story structure because people remember narratives. While writing a test, I map the logic into exposition, rising action, and resolution. If any phase is longer than a line or two, I use comments or wrapper functions to delineate the boundaries. But I can’t hide too much detail—the punch line loses its sting if you don’t know the Boss practices feng shui martial arts.

Don’t leave your app defenseless.


DILBERT © 2015 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Tie it all together

There are many elements to a comic strip: the dialogue, the characters, the scenery. These layers all converge on a single message. Do you see Rodney’s wrinkled tie? This subtle detail emphasizes just how unsafe the Boss’ new product is. Without pictures, variable names must evoke imagery that reinforces the behavior being tested.

Poor Rodney—no wonder his tie is wrinkled.


DILBERT © 2010 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

That’s all. I write short tests that focus on a single behavior. I name variables and functions carefully, and isolate state within each test. I ensure that the sequence of actions conveys a narrative structure. These elements of style focus the reader’s attention on my code’s behavior and foster clear understanding in a memorable way. I hope you find these cues helpful.

Love it? Hate it? Know any good jokes? Tell me what you think by dropping a note to