Confessions of a Developer 729x360

Confessions of a Developer

In our years as professional software developers, we have witnessed great injustices done in the name of a finished product. However, few brave engineers have the audacity to turn that watchful eye inwards and inspect their own dark souls.

We must admit our faults and surrender to the greater power of the API.

Let’s recite the software engineer’s 1010 steps program:

  • Step #0000:

    I admit that I have made mistakes. I am powerless to resist the allure of deadlines and shortcuts.

  • Step #0001:

    I accept that requirements may be underestimated by a power greater than two. Only by asking more questions will we ever approach sanity.

  • Step #0010:

    I must make a decision to turn my code over to the finite wisdom of compiler warnings and tracebacks as we understand them.

  • Step #0011:

    I will make an honest inventory of my skills and leave indescribable algorithms to the great library creators. I shall keep it simple.

  • Step #0100:

    I must admit to the project managers, the QA analysts, and to my code reviewer the exact nature of my bugs.

  • Step #0101:

    I will be ready to remove all these defects of software, no matter whose godawful code I find them in.

  • Step #0110:

    I will humbly ask my manager to remove organizational roadblocks which prevent me from refactoring bad code.

  • Step #0111:

    I must make a list of all the technical debt I have accrued and make a good faith effort to find resources to address it all.

  • Step #1000:

    I will make direct amends to our wronged codebases, except when to do so would delay a critical fix in production.

  • Step #1001:

    I will seek through profiling and debugging to improve our data’s contact with network, disk, and memory.

  • Step #1010:

    Having a technical awakening as a result of these changes, bless the supreme library creators and those mortals who surrender to their greater wisdom. Curse those who copy and then paste the first code sample on Stack Overflow.

I must not throw my responsibility over the wall, nor sweep exceptions under the rug. I will test not in production, nor shoot the messenger. As I follow these steps, I must submit my code commits to a higher source control repository.

When I attend a meeting, I will proudly admit — “I am a developer.”

223f2526 7eb8 43d4 8b42 be2446424e98

Drunk User Testing, A Sobering Idea

Can valuable insight into your UI be gathered from intoxicated users? Market research company Three Sheets seems to think so. As a former Quality Assurance Specialist, I am drawn to new testing methodologies. What are the reasons and benefits to performing this kind of testing?

In their own words:

We started Three Sheets because we, too, have fumbled our way through a smartphone app at 3AM. We’ve also failed at ordering nachos online, when we really, really wanted them. We understand the frustration of waiting in line at the post office to return two dozen pairs of shoes, a Mickey Mouse fun pool and that mushroom kit that never works.

Nowhere else will you find this combination of research acumen and customer empathy. So give us a call and we’ll tell you more about how our research experience can help transform your customer experience.

Choose Three Sheets Market Research. Because your customers drink.

~ | About Us

I can only think of a small set of businesses who could benefit directly from optimizing their website for the intoxicated; maybe pizza delivery, or taxi services? The whole Three Sheets website seems to be a little tongue-in-cheek and hard to take seriously.

It is a fact that 20% of all online shopping happens after midnight.*

* We think.

~ | Our Approach

I had to stop thinking of the users as “drunks,” and started thinking of them as clumsy, uninhibited, and truthful testers…

A rational person could hate the color of a website and simply not say anything. A rational person could get silently frustrated when a navigational element is hard to find but not report it. It is unlikely these UI issues would sneak past the uninhibited drunk. Of course, you wouldn’t go changing the color of your website because one drunk said so, but that gut-reaction may still be valuable to note, especially if the same feedback comes from multiple users. If an intoxicated person has trouble navigating your website, perhaps there is a way to improve the navigation?

Three Sheets Research has several videos of the user testing in progress and has highlights and a conclusion for each of four products: Nike FuelBand, Windows 8, MySpace, and Online Sneaker Design. You can watch them for yourself and decide if they are useful. I can certainly think of many ways to improve the testing process. Obviously testing one user per product is insufficient to form an accurate conclusion. A true testing initiative would call for a much larger sample size.

But even after you have done the tests on a large enough user base to draw conclusions, is that information more valuable than just using sober testers? If you had $3,000 in your QA budget, how much of that should be allocated for drunk testing? The practical answer very well could be zero. Unless, like previously stated, you literally need to optimize for intoxicated users.

I am interested in seeing a case study from Three Sheets Research. Until then, it is too risky and I will remain skeptical.