Monday, December 31, 2012

We are entering the darkest of Dark Ages. Happy New Year!

I recently found myself in a conversation with a Chicago taxi driver – we veered onto computers and questions and concerns around privacy and on to other technology-fueled social and ethical issues – an excellent ride (almost as good as a NYC taxi ;). At the end of our short ride, we came to a surprising conclusion; that there was no way for humanity to keep pace with the flood of advances flowing from computer science, biology, physics, etc. We were not talking about the actual underlying technical complexities – only the social, ethical and moral consequences, obligations and risks stemming from all of the above.
The gap between our visionaries and the rest of us is already far greater than existed in 10th Century and it’s only getting wider.   Now, the other distinguishing mark of the original Dark Ages was the drought of written records/history – very little is known about this “dark time” because of the lack of primary documentation. …but, as Charles Goldfarb outlined in a keynote (probably over 20 years ago), the rise of the digital record means that photos, videos, and every other form of record can be manipulated beyond detection – our modern age is “post history” – if pre-history is defined as before there were written records – our current ability to rewrite the recent past absolutely and without detection means we are now in a “post-history” phase.

As we welcome in 2013 – we are taking one more step deeper into a Dark Age like nothing we have ever experienced before and there is no telling if/when/how we will dig our way out (at least until we achieve “technical singularity"). So - HAPPY NEW YEAR!

Thursday, October 11, 2012

Who cares about application analytics? Lots of people for lots of reasons…

The results are coming in from our most recent survey on the current state of application lifecycle management and the use of application analytics.

Most everyone agrees that analytics are powerful - it's why they're powerful that gets interesting. 77% of development and their management identified “insight into production application usage” as influential, important or essential to their work, and 71% identified “near real-time notification of unhandled, caught, and/or thrown exceptions” in the same way (other choices were “moderately important" and "no importance"). 

…but where specifically do application analytics have the greatest impact?

Usage, behavior and patterns

Figure 1: Where does insight into production application usage matter? (click to expand)

Developers need to know where and how to prioritize the work that’s right in front of them and nothing makes supporting users more straightforward than having direct insight into what they’ve been doing in production.  

While third in the cumulative vote count, Product planning was ranked 1st in the “essential” categorization. If you don’t know what’s happening around you, there’s no way you can confidentially plan for the future.

Unhandled, thrown and caught exceptions

Figure 2: Where does insight into production incidents (all manner of exception) matter? (click to expand)

Not surprisingly, everyone can agree that insight into exceptions and failures in production provide critical insight into how future iterations of an application should be tested. The fact that 22% of respondents did NOT see exception analytics as being at least influential in customer support is somewhat surprising and will be the subject of future analysis – however, one potential explanation may lie in the obstacles development organizations face (or perceive) in actually implementing true feedback-driven customer support and development processes.

What’s getting in the way?

When comparing usage versus exception monitoring, respondents are mostly consistent in their ranking of obstacles – in fact, the consistency is striking when you consider the divergence in ranking of use cases across these two categories (usage versus exception monitoring). 
Figure 3: What are the obstacles preventing development organizations from implementing effective application analytics solutions today? (click to expand)

While specific numbers vary somewhat, development, product owners and management focus first on security and privacy concerns (see my last post) – followed closely by performance and stability – let’s call that Quality with a capital “q” and “Lack of Best Practices,” which is understandable as application analytics is only now emerging alongside new platforms, tools and methodologies.

PreEmptive Solutions and Application Analytics

What the respondents’ agreement in “obstacles” also indicates is that it should be possible for a single technology solution combined with appropriate processes and patterns designed to address these obstacles to meet the user and organizational requirements across all of these use cases and scenarios.  …and, coincidentally that is exactly what PreEmptive Analytics has been built to accomplish.

For more information on PreEmptive Analytics, visit

For an article I wrote for MSDN and the launch of Visual Studio 2012, checkout Application Analytics, what every developer should know.

Sunday, October 7, 2012

Security and privacy concerns identified as most common obstacle to implementing application analytics

This is the first installment of a series posts on the state of application analytics and modern application development patterns and practices.

In a recent survey that includes responses from 100’s of development organizations, two thirds identified application analytics as either essential or important in one or more of the following categories: Product planning, Development prioritization, Test plan definition, Customer support, and/or Development ROI calculation.

Among this group where application analytics has the greatest impact, the following were identified as the most serious obstacles to implementation. (click to enlarge graphic)

Obstacles preventing the use of application analytics in my organization 

Half of all respondents identified security and privacy - a 20% higher response rate than the next two closest obstacles e.g. lack of expertise and general quality concerns). 

The emphasis on security and privacy is even more pronounced inside larger development teams. Nearly 3 out of every 4 development organizations with greater than 50 people identified privacy and security as an impediment – 50% more likely than development teams of between 5 and 15.  

Correlating perceived obstacles to implementing analytics with development organization size

In fact, an organization’s size appears to have a significant influence on virtually every perceived obstacle; larger organizations appear to be more concerned with performance, quality and connectivity while smaller organizations struggle with awareness of analytics solutions, development best practices, and the required integration of their development and operations processes.  

One might make the generalization that, due to the complexities that come with size, larger organizations have had to move to more tightly integrated platforms and practices – putting them in a better position to implement application analytics (and so they focus on potential risks stemming from an implementation) whereas smaller teams may not have as an entrenched “feedback-driven” integrated approach to development. As such, they are more likely to struggle with how to move forward (keep in mind that all respondents identified application analytics as either essential or important).

Privacy and Security and PreEmptive Analytics

Regardless of development team size, privacy and security is the number one perceived obstacle – and PreEmptive Analytics is unique in its approach to this critical requirement. PreEmptive Analytics includes the following:
  • Development teams own their own data. PreEmptive asks for no rights to aggregate, inspect or resell your data.
  • A two-level opt-in switch is included ensuring user opt-in to transmit runtime data from both regular usage AND application exceptions. The logic itself can be injected post-build for .Net and Java and can always be defined by the development organization.
  • All data is, by default, encrypted on the wire.
  • Device ID's (if they are collected at all) are hashed before they are transmitted.
  • Tamper-detection and defense can be used to detect and defend against any attempt to alter or redirect runtime data transmission.
  • Obfuscation can be used to obscure inspection by third parties of what is being collected and transmitted.
  • Unique keys identify both the organization and the application source for data.
For more information on how PreEmptive Analytics addresses the number one obstacle for implementing application analytics (as ranked by those that need it the most), visit

Wednesday, October 3, 2012

Today’s DevOps: Pushmi-pullyu or kick#@s crew?

Most of us know Dr. Dolittle’s pushmi-pullyu – that special beast with two heads that go in opposite directions whenever it tries to move.  That this creature could only exist in a fantasy world free from Darwinian forces is obvious – doomed to failure because, while its blood may circulate, the pushmi-pullyu is literally of two minds whose “selfish interests” are forever at odds.

In the 2-person scull, rowing is executed in precise synchrony achieved through coordination and continuous feedback. Failure to stay in synch will list the boat to one side, slow forward progress, impede steering, frustrate rowers and serve as the root cause of numerous injuries.

Of course, competitive rowers invest in the best platform too (their racing boat or "shell"). Competitive shells are designed to reduce all manner of friction. A shell’s rigging is built to meet the distinct needs of each rower; accommodating unique requirements that stem from a rower’s relative position inside the boat (which should NEVER be confused with a conflict of interests between the two rowers).  

In fact, the underlying design principles presume that rowers share a common goal (win a race), have entered into a contract (to coordinate and synchronize), and are committed to working within an integrated platform (their shell).  …and the best rigging is one that finds a way to meet each rower’s unique requirements as measured by the achievement of their common goal.

The hallmarks of a successful DevOps organization (aka “the kick#@s crew”)

What’s it take to build a kick#@s crew and avoid breeding your own doomed pushmi-pullyu?

·        Agree on common goals (Dev ROI?)
·        Adopt processes designed to coordinate and synchronize DevOps activities through continuous feedback (Agile?)
·       Invest in an integrated DevOps platform built to reduce friction and able to meet the unique requirements of both development and operations.
·        Always be mindful that, if these unique requirements are not met (like in our sculling example), you will suffer slowed progress, impeded agility, frustrated stakeholders and all manner of inefficiency and loss.

These principles sit at the heart of PreEmptive Analytics and have helped ensure our success across industries, platforms and runtime environments.

I first blogged on the importance of understanding role based “special interests” relating to development and operations feedback almost two years ago to the day: Application analytics: a new game brings new rules  (10/12/2010)

For a more contemporary discussion of these topics, check out my article inside the MSDN Visual Studio Library: Application Analytics: what every developer should know

For more information on PreEmptive Analytics, visit


Friday, June 15, 2012

Chagrin Falls High School publishes mobile apps – and the fun has only just begun

I’m pleased to report that a project I had been nursing for most of this year has reached a milestone. At the beginning of this last semester, I kicked off a track inside our local high school (Chagrin Falls High School) to get teams of students collaborating on building mobile apps – not just programming but developing all of the skills required for a successful app launch.

Today, the first apps went live and they include:

Both apps are simple to begin with – BUT remember, these are the work product of a new and educational program where high school students work in small teams focusing on developing programming, product management and marketing skills.

These apps also generate usage analytics (nothing personally identifiable) and include a feedback page. Students will review the analytics and user feedback to improve future versions – so please download these apps, give them a spin, and provide feedback. Do it for the kids!

Of course, I didn’t run this program alone – I worked with The Chagrin Falls Dads’ Club and the Chagrin Falls High School administration with support from Microsoft (who provided mobile phones, development software and some technical support) and PreEmptive Solutions (who provided monitoring software to help measure app usage). 

The objective of the program is to organize students into teams where they would not only build a mobile app, but publish that app in a global marketplace and monitor its adoption and usage “in the wild.”

The goal of the program is to teach students the importance of the “total lifecycle” of an app from idea to creation to publication to adoption to continuous improvement. Obviously, today’s high school students are truly an “app generation” and it always kills me that the myriad of career choices beyond development are never highlighted – and given that this is an exploding multi-billion dollar market and I’m based here in Ohio – I wanted to make sure our local students knew what was available to them right now. What should be built? For whom? How is my app doing and what can I do better? Chagrin’s students will have a head start in knowing how to answer these questions in a global marketplace.

The process included organizing the early volunteers into teams and working with them to develop ideas that they could bring to market. Microsoft provided phones and software and had a technical resource drop in for some general instruction as well. PreEmptive Solutions provided the analytic software so that students could measure how their apps were doing.

Great work... Welcome to the North Coast.

A/B Testing: to grow your business, know your people

In early June 2012, the Yoga-pedia user-base surpassed the 60,000 user mark and, in spite of the app’s apparent popularity, I had to admit that I was not being particularly effective in monetizing this growing community. The Mobile Yogi’s business model has always been about white-labeling the fee-based “A Pose for That” for yoga studios, retailers and other wellness-centered businesses – Yoga-pedia was conceived simply to accelerate adoption of A Pose for That (see Increasing App sales with Analytics: Free apps versus trials) and, while Yoga-pedia does generate some ad revenue; the ads themselves were really intended to be little more than an irritant and, therefore, another reason to upgrade (the paid app is ad-free of course). …but I had a growing sense that this community was most likely an under-utilized (and therefore undervalued) asset; but how to turn this hunch into revenue?

I needed to find something that I could market other than an app upgrade.

First, I took stock of what I already knew about my users. I realized that the analytics that I had been collecting up until this time had certainly helped to improve user experience and software quality, I really had very little insight into my users’ interests and desires beyond their interactions with my app’s specific features. 

In fact, all I knew for sure about my users was:
a) That my users all have an interest in yoga (they use my app) and
b) When they were in my app, they are actually thinking about yoga at that moment in time.
– But how to parlay on my limited insight into something actionable? 

It was time to make the leap into A/B testing.  A/B testing is about randomly showing a user different versions of a page – the (A) version or the (B) version – and tracking the changes in behavior based on which version they saw. The (A) version is the existing design; and the (B) version is the “challenger” with one element changed.

The element I chose to vary was the “contextual ads” being served up, in this case, by Microsoft’s adcenter.  The B “challenger” was a set of 3 different faux ads promoting yoga clothing, yoga training, and yoga retreats as follows:

I randomized the displays by generating a random number between 1 and 4 as follows:
public static int MyAdOrServeAd ()
            int MyAdOrServeAd = 0;
            Random randomObj = new Random();
            MyAdOrServeAd = 0;
            MyAdOrServeAd = randomObj.Next(4);
            return MyAdOrServeAd;

And then set System.Windows.Visibility for each of the four controls (AdCenter and my three test topics above) to .Visible or .Collapsed accordingly, e.g.
if (RandomAd == 3)
                adControl3.Visibility = System.Windows.Visibility.Visible;
                My_AdRetreat.Visibility = System.Windows.Visibility.Collapsed; …

The result is the following A/B behavior:

And of course, I used Dotfuscator to inject analytics to track:
  • ·         Which “ad” was displayed in which page and
  • ·         What action (if any) users take with each flavor of ad.

I added the method, WhatAdWhen, that takes 3 string parameters, the page being shown, the ad being displayed, and the event, e.g. New Ad, Ad Engaged (clicked), or Ad Error (only applicable to AdCenter served ads).  The method does nothing, but I grab the parameters and send it to the Runtime Intelligence Service using Dotfuscator to inject the instrumentation.

The method is:
private void WhatAdWhen(string page, string ad_type, string event_type)

The call looks like: WhatAdWhen("Main", "Clothing", "New Ad");

And then attach the following extended attribute with Dotfuscator to track each call


The * is all I needed to include to have Dotfuscator send all three values to the Runtime Intelligence Service… So what did I see after a few days in production?

Perhaps not surprisingly, yoga-focused promotions outperform contextual ads by almost 10X – given my current volumes, I expect to generate over 3,000 highly qualified clicks per month. 

Now when I last checked, Google estimates that it would charge $150 per month for 175 clicks on “yoga clothing.” Put another way, Google would charge roughly $3,000 per month for the leads I can generate for my yoga business clients today (focusing only on US-based users – not global). Now that’s the seed of a business – build well-defined, highly sought-after communities (like yoga consumers) and then find ways to connect these communities to businesses that value them most. …and this compliments perfectly the original plan of delivering white-labeled yoga apps… with this evidence, we have already recruited some small yoga businesses to actually reduce their Google ad spending and divert those funds to pay for both white labeled yoga apps and the promotion of their businesses to my growing cadre of mobile yogis.

If you don’t measure, you can’t improve – and with in-app A/B testing, you can measure more than just software adoption – you can glimpse inside the mind and motivations of your users – and that is the key to any successful venture.

Sunday, May 13, 2012

Software Pirates protect their booty too (pun intended)

In the past 90 days, there have been 22,604 reported cases of hacked Dotfuscator use in 46 countries. For those who don’t know, Dotfuscator is a highly sophisticated piece of software that protects Intellectual Property inside apps, prevents software piracy and monitors application usage. What the above statistic is measuring are software pirates using pirated versions of Dotfuscator to protect their ill-gotten code. Does everyone see the irony? (I guess bank robbers need to protect their stolen money too)

Some of you may be snickering on the other side of your screens, “how good could this software be when 22,604 developers cracked their code?” – Well, as it happens, Dotfuscator was only cracked twice. These two instances were then distributed to thousands of these “application chop shops.” (thank to Morgan Reed, executive director of the Association for Competitive Technology for the new term - I think it's spot on). 

Also – these bad actors were NOT able to disarm our tamper alerts. Thanks to Dotfuscator’s tamper detection mechanism, I can share this unprecedented glimpse into what appears to be a massive, highly organized and well-equipped software piracy network.

Percentage of 22,604 tamper alerts from two hacked instances of Dotfuscator

The “46 country” count is also somewhat misleading. In point of fact, roughly 9 out of 10 of all incidents emanated from only two countries; China (75%) and Vietnam (12%). Interestingly, all of Vietnam (many many locations within Vietnam) used only one of the two keys whereas Chinese crooks used both – does this suggest two rather than one criminal network; one based out of China and another out of Vietnam?

Distribution of incidents by country of origin

So why should anyone but PreEmptive care?

Some of you may say – that’s just the cost of doing business in the software world – and, in this particular case, while relatively large, who does this hurt but PreEmptive?

To be honest, I don’t think I’m really the best person to try to communicate the enormity of the threat this data reveals. …And I have to thank my recent experiences as part of the Act Online Fly-in that have helped to open my eyes to the threats that this kind of organized attack on our IP and our apps represent. Anyhow, here goes... (NOTE - the greatest threats are last on this list)

First, the obvious one – when a software company is denied revenue, they cannot hire as many employees, pay as much taxes or contribute to our economy in a multitude of ways.

Second, when a hacked app also relies on external services (hosting, bandwidth, human support), these expenses are typically still borne by the true app developers.

Third, hacked apps cannot be trusted to be updated or to be as functionally reliable as the original. To the extent that poorly performing apps can cause damage to their users – this can become a public and personal safety hazard. (GPS, financial, etc. apps are often “mission critical).

Fourth, all of the privacy and security practices and ethical guidelines that legitimate software companies follow can be expected to be thrown out the door. Tracking, identity theft, hijacking of devices may all begin with a hacked/counterfeited app.

Pirated/look-alike/counterfeit apps may well be the single most unrecognized risk to consumers, children, and our economy – not just because of the lost revenue, but because of our dependence on this software (think about counterfeit cancer drugs and car parts as an analogy) and the intimate place these apps occupy on all of our devices.

Anarchy or organized attack?

Again, I am not the expert here – but lets revisit the Dotfuscator example one more time. Dotfuscator is a specialized software manufacturing platform that obfuscates and instruments MSIL (I realize that many of you will have no idea what I just wrote – that’s my point). Dotfuscator is embedded into serious, commercial software publishing platforms – each of the 22,604 sessions run over just the past 90 days represent ANOTHER app being built and readied for distribution into our infrastructure and economy. This is a tiny fraction of the massive production effort underway churning out applications that, in all likelihood, pose a material threat to each of us – even those of you that have nothing to do with software development.

Chinese and Vietnamese developers are clearly organized (they are communicating and sharing resources), sophisticated (as evidenced by their use of Dotfuscator), and prolific... Coincidence? 

Sunday, May 6, 2012

Ryan is Lying – (well, actually stealing, cheating and lying - again)

Back in January I posted Hoisted by my own petard: or why my app is number two (for now) where I profiled the pirating of my app content (from A Pose for That) and the steps I took to have Microsoft remove the offending app from the marketplace. Well, Ryan Lan AG is still going strong on the Microsoft marketplace (with 37 apps – what’s up with that Microsoft?) even though my particular app had been removed – OR SO I THOUGHT! Thanks to an eagle-eyed phone user (thank you – you know who you are), I discovered a new publisher on the marketplace – Ryan AG. Coincidence? I think not. 

Ryan AG has an app called A Yoga Course – which is the identical app with my identical (pirated) content. I have filed the requisite infringement complaint document with Microsoft – but, obviously, this is like stepping on a single cockroach – it’s not going to make my food any safer.

I think, while Microsoft is analyzing app submissions, they should be building an index of resources and flagging cases of reuse. I think publishers should be able to register “ownership” of their content resources and be notified when those resources are showing up in submitted apps. Publishers can do nothing or register a complaint – of course this 
a) costs time, money and resources and 
b) can be easily circumvented with some effort on the part of the bad guys – so, it may not be practical (but I would also welcome a better suggestion).

A two foot fence that “deters the opportunistic” and clearly delineates acceptable from criminal behavior would have, in my view, a net positive effect.

Who actually are the people behind Ryan (Lan) AG? I can’t say for sure, but I have a strong suspicion that whoever owns the email knows the answer to that – why not email him and ask what he is thinking about as he steals my content (and a host of others from what I can see).

You might think I may be jumping the gun here – perhaps this is an innocent naively unaware that they are crossing some invisible theoretical line. Perhaps they have a strong moral stand against content ownership or some other flavor of that malarkey – so… check out Ryan’s profile picture that can be seen here. This is not an ethical, cultural, or language issue – this is an unrepentant thief.

Wednesday, May 2, 2012

Mr. Smith (ok – Mr. Holst) goes to Washington

I’ll be heading to DC on Monday to meet with my elected officials (I’ll be joining up with another 40+ technologists). We’re all participating in the Association for Competitive Technology (ACT) Fly-In with a simple objective – to educate and inform our representatives and their staff on the tremendous opportunities (and potential risks) stemming from the emerging $20B app economy.

Our message is simple too.  The pace of innovation and growth taking place right now in the app economy is spectacular.   …and we need to do whatever we can to ensure that the app economy continues to grow – especially inside the US. What can the federal government do? We need to increase capacity for mobile connectivity (spectrum) – we need to ensure that developers can protect their intellectual property and efficiently license their work across a variety of marketplaces.  And of course – we need to strike that delicate balance of ensuring consumer privacy without stifling the internet economy (or handicapping US-based companies unfairly). 

The role of government is important – both in terms of what is should be doing – and in terms of where it should be holding back. The greater development community also has a critical role to play and has been working to find solutions on all of these fronts (including the folks at PreEmptive and my own work inside Qi-fense and The Mobile Yogi). …and we’re all looking forward to sharing our progress with our lawmakers next week.

My view is that an informed Congress will help all application stakeholders (both producers and consumers) to continue to flourish. Some of you may find this post a bit idealistic – but this will be my second jaunt to DC in this capacity; I “flew in” last year too – and, amazingly, I think it mattered. 

…and this year, well, I AM from a swing state after all. Go Buckeyes!

Thursday, April 26, 2012

Feedback driven development - it's like yoga for my apps

This is the second blog post inspired (provoked?) by Nobel Laureate Daniel Kahneman’s TED talk on our "experiencing selves" and our "remembering selves". The first installment applied his theory to User Experience (UX) design principles; this installment pivots from a user’s experience of their applications to an application’s experience of its users.

Kahneman’s thesis is that our remembering self (that part of the mind that organizes experiences into stories to be replayed) dominates our decision making and that our experiencing self (that part of the mind that is in the here and now and feels things like happiness) has little residual impact on our decision making. The root cause is evolutionary. Humans are programmed to re-live the past to better anticipate the future (so that we survive). So, when we think about the future, we don’t think of our future as experiences. We think of our future as anticipated stories (anticipated memories of experiences to be had).

Yet, if we allow our life to be dictated too heavily by these memories (that are incomplete and all too often inaccurate) – the imbalance between our remembering and experiencing selves will ultimately extract a huge emotional, psychic and physical toll.

This explains why practices like yoga are so transformative and powerful to so many; yoga is all about restoring balance. Yoga is about being present physically, emotionally and spiritually – yoga is designed to offset our evolutionary programming of re-living the past to anticipate the future.  

An application’s programming is the polar opposite; an application lives 100% in the present. An application operates as pure “experiencing self.” At every given moment during an application’s lifecycle, it is the sum total of its software state, data values, exception handling, etc.) with no rendition of the past and no notion of the future. This complete lack of contextual awareness – of always and only being in the moment - is an imbalance of its own and just as unhealthy as someone who is never in the moment. User experience, software quality and security gaps are often, at their root, tied to an application’s poor contextual response in production; the absence of historical data and heuristics (a remembering self) causes all sorts of problems for an app and its users – and all sorts of grief for its creators.

The source of our respective dysfunctions (people and apps) can be traced to the differences in our respective genesis; people evolve while applications are created. Here’s the rub. Apps may not worry about the success of future generations (iterations) – but their creators do!  What are the practices that we, as application creators, can follow to ensure application balance (to optimize user experience, quality and ROI)?

Question: What is the application analog to yoga?

Answer: Feedback driven development and automated operational response to runtime behaviors.

To bring balance to applications means offsetting an application's bias to always be in the moment just as yoga offsets our tendency to be everywhere BUT in the moment. Feedback driven development and the increasingly automated and sophisticated operational responses to application events (DevOps) are designed to do just that – to ensure that both production applications and their future iterations are increasingly responsive and effective over time.

Now before we go too crazy – lets agree that analogies are not tautologies (or else we wouldn’t need two different words would we?) so we can only go so far with something like this – but here’s a little table that maps this out…

Yoga stuff
Development stuff
How they line up…
Physical, mental and spiritual well being
User experience, software quality and development ROI
What it is we’re trying to get right (fine tune)
Yoga Sutras
Agile Methodology
An organized approach to restoring balance
Hatha Yoga
ALM & DevOps
The dimension of the practice focused on the real world.
Patterns and practices
Pose[s] or pattern(s) you can hold/implement with ease

Whether or not your willing to follow me on this yoga analogy - I think the fundamental point is that a balanced development process (and an app with maximum ROI) must make it easier for development to improve future iterations and operations to manage. Conversely, its unhealthy (unproductive) for development to favor its inherent bias - to build applications that merely meet predefined functional specifications;  it serves everyone's selfish interests to invest in practices and technologies that connect applications in production to development and operations. 

Monday, April 16, 2012

AT&T What a difference a year makes

About a year ago, my wife had gone into a local AT&T store to ask about getting a Windows Phone. The sales person wouldn't recommend one assuring my wife that there was no interest at all. The rep did confirm that Windows Phones did run Android (yes, that's what she was told).

About three months later, I visited the same AT&T store (in Legacy Village, Ohio) with my wife to activate a Windows Phone and took the time to chat up the same associate. This time she knew that the phone ran under a different operating system - she still assured me that there was little if any interest in the phone. She was happy to activate a new account for my wife using our phone and we were on our way.

My wife's phone had a flaky battery and when I revisited the same store (and saw the same associate), she remembered me (because i had shown her my app) and swapped out my battery. Great service - thanks!

This weekend, I went in to upgrade my wife to the Lumia 900 (Cyan of course). I was helped by the same associate (I swear - it's the upside to living in NE Ohio i guess), and I asked her how sales were going. She said that the phone was hugely popular - that they had gotten a shipment of phones on Friday and they were already gone. ...but for me, this was the kicker, she said, without prompting, that she wished she could swap out her iPhone for the 900 - she loved the phone!

Now, I always joke that I don't drink the cool-aid because I am the cool-aid - but here is a young woman who went from ignorance, to disdain, to tolerance and has just landed on envy. This thing might actually take-off!

Tuesday, February 14, 2012

Colonoscopies - The secret to happy users and happy apps

Of course, I love any discussion that revolves around apps and people (symmetry – not just interaction) and so I was naturally blown away by a TED talk by Nobel laureate and founder of behavioral economics Daniel Kahneman on how our "experiencing selves" and our "remembering selves" perceive happiness differently.

To quote from the abstract, “[Kahneman’s] new insight has profound implications for economics, public policy -- and our own self-awareness” – but why stop there? Let’s add “user experience” (UX) on the human front and “ALM and SDLC” on the app front. This topic is going to be kind of long, so I’m going to break up UX and ALM and SDLC into two installments; let’s do UX first. 

Kahneman’s independent research offers some of the strongest evidence yet on the importance of using stories in operations and support, app design, user training, and in product management. 
Here is how Kahneman begins his lecture – and, if you substitute “user experience” with “happiness” and “app” for “life” and “value” for “well-being,” I think his message is a profound one for developers to hear.

Kahneman concludes that “we don’t choose between [user] experiences, we choose between memories of [user] experiences. Even when we think about the future, we don’t think of our future normally as [user] experiences. We think of our future as anticipated memories.”

“Everybody talks about happiness these days. […] There is a huge wave of interest in happiness, among researchers. There is a lot of happiness coaching. Everybody would like to make people happier. But in spite of all this flood of work, there are several cognitive traps that sort of make it almost impossible to think straight about happiness.

[…] This applies to laypeople thinking about their own happiness, and it applies to scholars thinking about happiness, because it turns out we're just as messed up as anybody else is. The first of these traps is a reluctance to admit complexity. It turns out that the word "happiness" is just not a useful word anymore, because we apply it to too many different things. I think there is one particular meaning to which we might restrict it, but by and large, this is something that we'll have to give up and we'll have to adopt the more complicated view of what well-being is. The second trap is a confusion between experience and memory; basically, it's between being happy in your life, and being happy about your life or happy with your life. And those are two very different concepts, and they're both lumped in the notion of happiness. And the third is the focusing illusion, and it's the unfortunate fact that we can't think about any circumstance that affects well-being without distorting its importance.

Now, here it is after I have made my mangling substitutions:

Everybody talks about User Experience these days. […] There is a huge wave of interest in User Experience, among researchers. There is a lot of User Experience coaching. Everybody would like to make people have better experiences. But in spite of all this flood of work, there are several cognitive traps that sort of make it almost impossible to think straight about User Experience.
[…] This applies to laypeople thinking about their own User Experience, and it applies to developers thinking about User Experience, because it turns out we're just as messed up as anybody else is. The first of these traps is a reluctance to admit complexity. It turns out that the (term) "User Experience" is just not a useful (term) anymore, because we apply it to too many different things. I think there is one particular meaning to which we might restrict it, but by and large, this is something that we'll have to give up and we'll have to adopt the more complicated view of what value is. The second trap is a confusion between experience and memory; basically, it's between having a good experience in your app, and having a good experience about your app or being satisfied with your app. And those are two very different concepts, and they're both lumped in the notion of User Experience. And the third is the focusing illusion, and it's the unfortunate fact that we can't think about any circumstance that affects value without distorting its importance.

Now this is just the opening of the lecture and neither version really proves anything – he’s just setting the stage – let’s look at two examples he cites to make his (and my) point.
First, he recounts the story of someone he’d met who’d been listening to a symphony, that “was absolutely glorious music” but at the very end of the recording, “there was a dreadful screeching sound” that “ruined the whole experience.” But it hadn't. What that screeching sound had ruined were the memories of the experience. He had had 20 minutes of glorious music but they counted for nothing because he was left with a ruined memory “and the memory was all that he had gotten to keep.”
How does this relate to user experience? Well, if your app is cruising along and your user is having a blast and then BAM! your app crashes or their work is lost or or or – their 20 minutes (or even 20 hours) of positive user experience is wasted when that one “screeching sound” that is your app’s failure wipes it away.

…but it works the other way too…

He retells a well-documented study of two patients undergoing colonoscopies; patient B was subjected to a particularly painful exam that he verified by reporting on his pain every few minutes. BUT the last few minutes of his exam had no pain whatsoever. Patient A was subjected to a less painful exam – BUT their exam had the moderate-level pain throughout their relatively shorter and less extreme exam. Clearly, patient B suffered more -- their colonoscopies were longer, and every minute of pain that patient A had, patient B had, and more.

…And now Kahneman delivers the punch line; "The surprise is that Patient A had a much worse memory of the colonoscopy than Patient B.” The stories of the colonoscopies were different, and because a very critical part of the story is how it ends. It was much worse for patient A than for patient B in memory. “What defines a story are changes, significant moments and endings. Endings are very, very important and, in this case, the ending dominated.”

When something goes wrong for your user, the story isn’t over unless you let it be over. If you can get back to your user and fix or at least address their issue in some timely fashion – their memory (of their user experience) can be rehabilitated just as dramatically as it was decimated in the previous example.
Kahneman’s conclusion works for UX and app developers …

“We don’t choose between [user] experiences, we choose between memories of [user] experiences. Even when we think about the future, we don’t think of our future normally as [user] experiences. We think of our future as anticipated memories.”

Kahneman’s independent research offers some of the strongest evidence yet on the importance (criticality) of using stories in operations and support, app design, user training, and in product management.
Coming next: do apps have an experiencing self and a remembering self? You bet! (After all, they’re people too!)

Wednesday, February 8, 2012

Which came first, application development or the egg? … and other riddles of the day

Spoiler alert, the answer involves butterflies and trees.

Q: When a tree falls in a lonely forest, and no animal is nearby to hear it, does it make a sound?

A: Of course, the answer is No. Sound is vibration, transmitted to our senses and recognized as sound only at our nerve centers – If there be no ears to hear, there be no sound at all.

Q: BUT, when a tree falls in a lonely forest, and no animal is nearby – does it matter?

A: Yes and its impact goes beyond the sleeping caterpillar in its cocoon = Consider the Butterfly effect where a small change at one place can result in large differences somewhere else (the name comes from the example of a hurricane's formation being dependent on whether or not a distant butterfly had flapped its wings several weeks before).

Q: When an app crashes in the wild and no developer is nearby, does it create a work item?

A: Sadly, the answer is No. Work items are specific tasks, transmitted to a dev organization and recognized as a work item within an IDE like Visual Studio. If there be no IDEs, there be no work items.

Q: BUT, when an app crashes in the wild and no developer is nearby – does it matter?

A: Yes and its impact goes beyond the individual user inside your app = consider the operational, reputational and social implications of a crushed user and the impact that a small incident in production can have.

A production incident can result in massive user defections, cratered development ROI and operational failure. (Don’t make me go into “for the want of a nail…”)

The material distinction between the hurricane and the “operations storm” is that while we can only forecast the weather, with the right information, development (dare I say “devOps”?) can effect operations through AGILE practices.

Q: Which came first, the chicken or the egg?"

A: Of course, it’s the egg. Just ask the dinosaur back in the Triassic Period. The question as to which came first, the chicken egg or the chicken – well that’s a metaphysical question and has no place in a thinly veiled software blog like mine.

Q: Which came first, application development or operations?

A: Of course, it’s application development. Just ask the original time sharing providers back in the 60’s. The question as to which came first, the "development practices that are responsive to operational feedback" or operations is, in fact, one that I’m prepared to answer (as opposed to that chicken/egg deal).

Most applications today are deployed like the proverbial tree in the lonely forest – making no noise (because there are no developers around to listen) but whose crashes often reverberate across operations and then hit development like a hurricane.

Application Analytics is the emerging discipline plus supporting technologies specifically designed to connect application adoption, user behavior and production incidents to development practices, quality and impact.

Application Analytics is the evolutionary trigger that moves “the application” from the Triassic Period into modern times where cloud, mobile, web services and other forces are transforming our ecosystem.

If application analytics isn’t a part of your development process, well…. You just may end up in a mud pit with the rest of the dinosaurs.

Monday, January 9, 2012

Hoisted by my own petard: or why my app is number two (for now)

I have to admit that I have taken some small pride in the fact that my app, Yoga-pedia, has been the number one yoga app on the Windows Phone marketplace since its debut over the summer. Imagine my surprise when I checked the marketplace today and found another yoga app in the lead!

Of course I had to know what made this app so special and so I clicked through to check out the competition. OK, the cover art shows a barely clad buxom brunette in some faux pose – “it’s one of those apps” I said to myself; those soft-core apps that are all about titillation and little else.

Needing to satisfy myself that I had this app pegged, I quickly scanned the description… what’s this!? “No matter what your issue, there is most probably a pose for that” – that’s my line (after all, my paid app is “A Pose for That”). My eyes dropped to the screen shots – no way! – Other than the home page, the screen shots were lifted right out of my app!

This free app included the four yoga instruction videos only included in my paid app. Just to be clear, these videos feature my wife as the instructor, I filmed the videos (and even composed and recorded the music).

I’d been beaten by my own content!

Two things happened in quick succession; first, I got really pissed; and then I was awash in a flood of questions…

  • Who the F#$! is behind this? (and please let me meet them one day)
  • How did they do this? (and is there something I could have done to prevent it?)
  • What can I do about it? (and how much of my time is this going to suck up?)
  • Is this a common problem (if so, why haven’t I heard about this before?)
  • Why did they do this? (they don’t show ads and the apps are free)
  • What other apps does this publisher have? (and are they also stolen?)
  • And do I tell my wife? (because she is going to be even more pissed than me)
Who’s behind it? Well, I can’t say for sure – the company name has no other reference on the web that I could find – but they’re out of China and I am working on a few leads…

How did they do it? I believe they downloaded the XAP from the marketplace and while they couldn't take my code (it’s not in their app), they definitely lifted my resources (they are named identically to mine including spelling mistakes). Obfuscation/encryption can protect the code – but did nothing to shield my external resources (like the videos).

What can I do about it? Microsoft has an established process that I have initiated – I’ve been led to believe that they will act swiftly given the unequivocal evidence I was able to develop. If this is all there is to it, Microsoft has made the process straightforward (I will post more if it’s more involved).

Is this a common problem? I have no idea – can someone else share?
Why did they do it? I really don’t know – BUT the pirated version of the app uses
  • music and video library
  • phone identity and
  • data services
There is no reason to use these services to play my four simple videos – is this malware? Phishing? What are they doing with this app? I’ll have to take a closer look – I expect (hope) Microsoft will too.

What other apps does this publisher have? Some over-the-top soft-core apps and a collection of language apps – I suspect all of these are “resource-heavy” with little or no exposed app logic (so they are all stolen) – they are driving adoption for sure – but to what end?

And, last but not least, do I tell my wife? Well, of course I did and, yes, she is pissed – especially when I explained that there is no way we are suing anyone in China for copyright infringement.

At the time of this posting, the offending app is still live - but to be fair, it’s been 5 hours since I discovered the app, 4 ½ hours since I first contact Microsoft, 3 ½ hours since Microsoft gave me the contacts and process to begin the take down process, and 2 hours since I initiated the process.

I’m coming for you Ryan! (and you'd better hope that I get to you before my wife does)


The offending app has been taken down by Microsoft. It took 24 hours and, as I tweeted earlier, given the legal hoops I'm sure Microsoft had to jump through, I think that's pretty good.

On the other hand, the bad actor, Ryan Lan AG, still has 10 apps on the marketplace. I think publishers who so blatantly abuse their fellow publishers should be blacklisted. ...but that's just me. Ryan - you want to man-up and identify yourself?

Blog Archive