The one question I always get while talking to people about First Opinion is, "How is the quality?" On the surface, quality seems like such an easy thing to measure since most people (myself included) usually only view quality in terms of results: I have a problem, I seek a solution, that solution solved my problem, so it was a quality solution.

But in actuality, a quality experience can be much more nuanced and can change depending on the circumstances of the person and their expectations with regards to not only results, but also speed and empathy. I think this anecdote from The Innovator’s Prescription demonstrates quite nicely how fluid the definition of a quality experience can be:

We'll illustrate how the definition of quality health care can change by recounting the experience of a friend, whom we'll call Helen, whose youngest daughter woke up on a recent winter morning with an earache. Having seen the symptoms dozens of times before, Helen called their pediatrician. "Katie has an ear ache," she said. "I bought an otoscope a few years ago because this happens so often with our children—and Katie's eardrum is bright pink. Is there any way you could just call in a prescription for ampicillin to our pharmacy?"

"No, I can't do that," the pediatrician replied. "I really need to see her."
"Can I bring her in this morning?" Helen asked. "She's in a lot of pain, and I have a busy day at work."

"Unfortunately I'm booked all day—but if you bring her in at about two o'clock, I'll see if I can work her in," was the reply.

Helen arrived with Katie at the pediatrician's office at 2:00 P.M., and waited for two hours before the doctor had time to see her. Then in 30 seconds, with one look in her ear, the doctor diagnosed, "She has an ear infection."

"That's what I told you this morning!" Helen grumbled in frustration. "We need to get home because the older kids are home from school. Can you please give us the prescription?"

The pediatrician then wrote out the prescription. After a 10-minute drive to the pharmacy and another 20-minute wait, Helen and Katie drove home with the medicine they needed. The process, which is played out tens of thousands of times every day in America, cost Helen four valuable hours.

Was that a quality experience? Helen got her desired result, but the lack of speed and empathy resulted in an overall poor quality experience. In fact, I think there are even times when speed and empathy might actually be more important than just results alone, especially in situations where the desired result might not be completely obvious.

I want you to close your eyes and imagine being awakened abruptly, in the middle of the night, by the crying screams of your three year old daughter. You rush into her room to find your daughter, and her bed, covered in throw-up. You jerk off the covers and strip off her soaked clothes. As your wife works to calm her down, you start to clean up the mess. Then, ten minutes later, your daughter throws up again.

Your wife pulls out her phone and sends a message to her doctor (using First Opinion of course) to see if her doctor has any thoughts on what could be wrong. Within 15 minutes, your wife and her doctor are messaging back and forth--in the middle of the night. In this situation, there was no real result to be had with that conversation with her doctor, but this was a quality experience nonetheless, not because the problem was solved, but because the response was quick. The experience wouldn’t have been nearly as high quality if that conversation had happened just one hour later.

Now I want you to close your eyes again and imagine you’re a new parent, you’ve only had your baby home from the hospital for a few days, and she’s having trouble sleeping, you’ve tried everything you could think of to help her sleep, you’re tired, and you’re baby still isn’t sleeping. Your wife convinces you to take her and the baby to the Pediatrician, so she can talk to him.

At the office, the doctor pokes and prods your daughter with his finger for a bit, takes some measurements, and tells you she’s healthy and asks if you have any questions. After you run through your list of what you’re doing to get her to sleep, he sits down for a minute and talks about how frustrating it is when babies aren’t sleeping, and how he’s been through it himself with his kids. He assures you it’s normal and that he thinks you’re doing a great job and that he’s sure she’ll start sleeping soon.

Once again, there was no direct result to be had from that doctor visit, but this was still a quality experience because the doctor was there for you, to tell you he thought you were doing a good job, to empathize with you.

I, of course, don’t need to imagine the above scenarios because they both happened to my wife, our daughter, and me. And so I know they were both positive experiences and high quality interactions with our doctors. These are the exact type of experiences I hope you have with your First Opinion doctor, so, if we ever meet in person, I can ask you, “How is the quality?” and you can share a similar story to me.

Designing and building software is all about tradeoffs. As a developer, I usually begin the planning phase by mapping out the ideal way I would like to interact with the software. If this is an iOS application, I ask how I would like my program to behave with certain input, what does it do when I swipe left? How about swiping right? If this is a new library, I map out how I would like to interface with this library. After mapping out the ideal interface and interaction, then the realities of actually building that ideal creep in.

At First Opinion, we decided early on that passwords were annoying on a mobile device and so our app would use uniquely generated tokens when signing up on the app. Basically, a user would sign up using their device and then their account would be locked to that particular device, they would always have access to their account (on that particular device) and they would never even have to think about a username and password. Then, if they ever tried to use First Opinion on another device, we would see it wasn't their validated device and send them an email with a registration code that they could then enter into their new device to tie their account to that new device. No usernames or passwords would ever need to be remembered by the user.

This was the ideal user interaction with First Opinion that we wanted. But that ideal changed as we went along actually building the app. First, as developers, we spend a lot of time logging in and out of the app, and so we kept delaying the email with validation code part of our signup flow because it was not only complex to implement on the backend, but would keep us from easily moving between devices and logging in and out to test the app. Since the validation of users didn't exist, and there were no passwords, during the early days of the app everyone could sign in as everyone else. Obviously, this was going to have to change by the time the app was released into the wild.

As we got closer to launch, we realized how much architecture was really needed to support sending the validation emails. Things like a temporary storage place for those registration codes and an architecture for sending emails. Basically, there needed to be lots of stuff to allow the user to not have to remember a password, and that was on top of the rather large list of other things that still needed to be done before launch, we're a relatively small team (currently three engineers) and we needed to focus our attention on what was absolutely necessary for launch.

So, after a few debates, we decided to compromise between no credentials and a full fledged password, and add a passcode. A passcode feels lighter than a password, and its easier to remember (hopefully!). But most importantly, adding the passcode allowed us to remove all that needed backend work from our plates. What did it take to add the passcode? A slight modification to our user schema and some hashing code to turn the plaintext passcode into a secure hash. Total time spent adding and testing the new passcode was about an hour (at most), I'm guessing doing it the other way would've taken a few days and most likely wouldn't have been as reliable (what happens if the email is delayed? What if it doesn't come at all?).

Arguably, the user lost a bit in this decision, they now have to remember a passcode, but by balancing the needs of the user with the needs of the developer, I think we were able to build an overall better, more reliable product. Most times, in the end, the user doesn't end up with your ideal interface, but hopefully you find the right balance between what you wanted, and what you ship.

I've pretty much always built my own blogging engine. In fact, I've spent more time building blogging engines than I've ever spent actually writing blog posts. The previous version of marcyes.com was built around the end of 2006, a few months after finishing my Computer Science degree, while I was waiting to start my first real job as a Patent Examiner at the PTO.

I was actually quite proud of that little blogging engine, it had all the common bloggy things of the day (trackbacks, comments, and rss) and a few others that no other blogging solutions had at the time (ajaxy image file management, expanding text boxes, SQLite backend, and link caching).

But over the last few years I've realized just how long in the tooth my blog had become (I hadn't touched the code in years, and it also hadn't had a design refresh), lots of whiz-bang features no longer worked quite right due to newer browser incompatibilities (but it worked in ie6) and just plain newer versions of everything. Also, I used my blog for a lot of non-blog things that I eventually replaced with other, better services. For example, my blog would cache links locally and make them searchable (using Lucene), but so could Evernote and it was available on my phone. It also turns out I don't blog much, so I don't have a lot of readers, and therefore I don't have a lot of comments (good thing I added all that comment moderation stuff), or rss subscribers, so those features got built, but never really got used.

Since my blog no longer worked quite right, and was way outdated aesthetically, I mostly stopped blogging altogether until I could update the software (the last public post was May 7, 2012, and the last private post was on March 12, 2013). Well, I've finally sat down and built a new blogging engine and gave the design a new coat of pain (with custom fonts and everything) :)

Why didn't I just use Wordpress?

I love Wordpress, but I think this answer from Marco Arment pretty much sums up my feelings on the matter also:

I'm a programmer, it's what I do.

I like building things, it's not only what I do, it's what I enjoy doing. Also, I like things a certain way and all the other blogging engines didn't do things exactly how I wanted to do them, so I wrote one that did do things exactly how I wanted to do them. Hopefully, I'll even blog a little more now.