Many of our users are probably familiar with the βunique error phraseβ that shows up whenever our application crashes in some way. These have a curious form, and we wanted to share the motivation behind them.
When diagnosing problems, itβs helpful to be able to associate a specific customer incident with information in the logs. Whenever our app crashes, we generate a unique ID for the incident, which is shown to the customer so that they may include it when they write in to us about a problem. This is not a novel practiceβitβs actually fairly primitiveβbut given an ID our staff can jump directly to more technical information on the customerβs issue, letting us classify and respond to it more quickly.
What is novel in Asana is the form these IDs take. In most other applications, a customer-facing ID is usually a long jumble of numbers and/or letters. There are lots of small, subtle drawbacks to representing a number to a human this way, and so for the sake of curiosityβand to add a little levity to an otherwise frustrating situationβwe tried something different.
Imagine representing 32 bits of information (numbers up to 4 billion) as a sentence instead of a jumble of digits. Each sentence can have the same predictable structure, and the number will be used to choose words from a dictionary to fill in that structureβlike Mad Libs.
One possible sentence structure can be: count + adjective + plural noun + verb + adverb, e.g. β6 sad squid snuggle softly.β We can divide the bit-space of the number like so:
5 bits for the count (2-33, so it is always plural)
7 bits for the adjective (one of 128 possibilities)
7 bits for the plural noun (one of 128 possibilities, which we made all animals just for fun)
7 bits for the verb (one of 128 possibilities)
6 bits for the adverb (one of 64 possibilities)
Now, given a dictionary containing words categorized in this way, we can generate 4 billion unique (and sometimes very memorable) sentences. In Asana, the ID used to generate the error phrase is random, so the same sentence is unlikely to occur twice.
Since we care deeply about providing users with a stable experience, we have put major effort into a system which records problems that occurΒ anywhereΒ in our application, whether on our servers or in customersβ browsers. It collects a bunch of useful information about the crash (stack traces, log snippets, application state, user and session information, etc.) and automatically groups similar problems and imports them into an internal Asana task list, pictured below.
Having all of the issues in Asana allows us to see aggregate information on each problem, such as the number of occurrences and different users it has affected. From there we can tag, prioritize, and assign it so it gets fixed. This system makes Asana a very effective issue tracker for us, as each issue has lots of important metadata associated with itβincluding, of course, a way to find it from a unique error message reported by a user.
So, in the event you experience a crash, rest assured itβs already on the list for our team to act on. And we hope you at least get a gem as a consolation prize. 12 soft kittens cuddle warmly. Or 8 mad orcs stomp loudly. Or .. you get the idea.