Prediction Score Card

| 8 Comments | 1 TrackBack
PredictionDocument.png

When I worked at a larger company, as an Apple Event approached work conversation would take second place to speculation about what Apple would announce. Lunch time conversation was consumed with a battle of predictions and the white board in front of my office became the location for people to publicly make their claims. After the event we would gather around the white board and collectively determine who did the best.

I'm sure I'm not unique in this tradition among Apple fans, so in an effort to support this fun, I have created the Prediction Score Card. Download it, print it out and take it to lunch. Amaze friends with your understanding and sophisticated analysis of current reports! Show your strength of judgment in the face of swirling uncertainty!

Have some fun.

P.S. If I have missed a rumor, please let me know and I'll add it, but be quick, Wednesday is not that far away.

Prediction Score Card.pdf

Update 1: Since I posted this Apple has approved my app Prediction which can be found here.

Update 2: Our servers have been slammed by John Gruber's linking to us. We're working on it.

Update 3: We're back online!

Algorithms and Economics

| 2 Comments | 0 TrackBacks

In college I was first introduced to this definition for algorithm:

An algorithm is a sequence of unambiguous instructions for solving a problem, i.e., for obtaining a required output for any legitimate input in a finite amount of time.1

An algorithm is a defined process for getting something done. Algorithms are all around us. Recipes are common algorithms. Driving directions can be algorithms. Your morning routine might be an algorithm. How we do the things we do can often, but not always, be described as an algorithm.

In the study of algorithms, we often consider the analysis of how a process scales. That is, as inputs to the process grow to incredibly large sizes, we ask and answer the question: "What factors dominate in determining the cost, both in time and resources, of this process?" The answers to this question often take the form of common mathematical growth functions shown in the diagram below:

growthFunctions.png

As you move across the x-axis you can see that each of these functions grows or increases along the y-axis. While they all grow, they do so at different rates. For example, the linear growth rate is greater than the logarithmic growth rate. In fact you can visually compare each of these curves rather easily for these small values of x, but doing this visual comparison for small values isn't where algorithm analysis normally starts. Remember the point of all this is to answer the question, "But how does it scale?" or "For very large inputs (values of x), which function increases the least?" If an algorithm's representative growth function can scale well, there's profit to be made.

For example, below is a basic chart of possibly the worst of all algorithms for sorting a list of items, namely, Bubble sort.2 Imagine a machine you pay to sort items using Bubble sort. The amount you'll have to pay depends on the number of items you ask the machine to sort. The x-axis shows the number of items to sort and the y-axis shows what it will cost, in dollars.

bubbleSortMachine.png

As you can see, the cost of this algorithm grows rapidly. With only 35 items to sort, this Bubble sort machine would cost you well over $1,000 to do the work! You might recognize this graph; it is the graph of an n2 function. Any algorithm that grows its cost in a way that follows the general form of an n2 function we call an n2 algorithm.

The "cost" of an algorithm depends on what you count. In the previous example we counted dollars spent on sorting the items. For computer algorithms the costs normally counted are space and time. Time measures how long the algorithm takes to complete as the number of items increases. Space measures how much extra memory or disk space is needed to complete the algorithm. In other fields, an algorithm's "cost" might refer to other things like money, people required or even distance traveled.

There are only a handful of general functions that are used to represent an algorithm's cost. Here they are:

ClassName
1Constant
log nLogarithmic
nLinear
n log n"n-log-n"
n2Quadratic
n3Cubic
2nExponential
n!Factorial

It is important to note with these functions that when the number of items to process is very small, the cost difference is also relatively small. For example, consider the relative cost of processing 5 items using different algorithms, each with a different efficiency type or class. Of course, the dollar costs shown below are fictional, but it should help you compare the different kinds of algorithms. The cost difference between each class of function follows:

ClassNameCost for 5 items
1Constant$1.00
log nLogarithmic$0.70
nLinear$5.00
n log n"n-log-n"$3.49
n2Quadratic$25.00
n3Cubic$125.00
2nExponential$32.00
n!Factorial$120.00

This table orders the function types from least expensive to most expensive at large-scale, that is, when the number of items to process is much larger than five. Even so, some of the more costly functions (Exponential for example) are actually cheaper when considered for only 5 items. Normally, algorithm analysis ignores cost at small-scale and looks at what the relative costs are when things get really, really big. Let's look at 1 million items. That's a big number, and for most people, if they sell or work with 1 million things, that qualifies as a large-scale system.

ClassNameCost for 1,000,000 items
1Constant$1.00
log nLogarithmic$6.00
nLinear$1,000,000
n log n"n-log-n"$6,000,000
n2Quadratic$1,000,000,000,000
n3Cubic$1,000,000,000,000,000,000
2nExponentialToo large to include!3
n!FactorialMuch too large to include!4

At large-scale, this kind of analysis begins to make sense. With 1 million things to process, you can really see how the order of growth changes dramatically. If you were responsible for a manufacturing plant and had a process whose cost function was an n2 function and you were able to change the process to something that cost more along the lines of a "n-log-n" function, well, you'd have a competitive advantage of $999,994,000,000! That is probably enough to get you that next promotion!

Taking the time to look at your processes, or algorithms, and improving them can result in amazing economic benefits when you are working with large-scale systems. Small changes, even seemingly simple modifications in a core or costly work process can add up to huge economic returns.

What we've been discussing has a name and it is called: asymptotic complexity analysis. It's called this because as an algorithm approaches very large inputs, the cost graph "looks like" or "asymptotically approaches" one of the key functions mentioned above. For our purposes, the word complexity simply means cost.

Economics

What does this asymptotic complexity analysis have to do with Economics? Consider this definition for Economics:

Economics: the branch of social science that deals with the production and distribution and consumption of goods and services and their management.5

Algorithms can optimize production, distribution and consumption, and these advancements can save time and money and drive economic growth. There are large economic incentives to scale up your business and reap the rewards that come with increased size and algorithms can help you do this. Remember, algorithms define how you do what you do, and at large-scale, they really matter. The following examples should better illustrate the value of algorithms in production, distribution and consumption of goods and services.

Production

For years the US Constitution has protected manufacturing algorithms in the form of process patents. These limited monopolies began with these lines in the Constitution:

"The Congress shall have Power ... To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;"6

The constitutional patent protection has been further clarified as follows:

"Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement therefore, may obtain a patent therefore."7

The ability to secure a process patent for exclusive use has obvious economic value. If you are able to discover and patent a new, more effective process for producing a chemical, drug or other material, the process patent offers a legal protection for your algorithmic advantage. It is for this and other reasons that capturing process patents offer a significant financial incentive.

The patent protection of algorithms is not new. The first patent for a chemical process was granted in 1793 for a process used to make potash.8 Since then many famous chemical processes have been patented.9

While there are those who criticize the patent system, even some of the most ardent opponents of the current system have concluded "the patent system still appeared to offer positive innovation incentives for drug and chemical firms."10

To summarize there are at least three key ways algorithms have a significant impact on economic production:

  • Better algorithms can lower production costs
  • Better algorithms can allow production to scale
  • Better algorithms patented can provide a competitive advantage

As companies deal with market pressures, algorithms-their discovery, improvement and protection-are an important part of doing business.

Distribution

When we think of the distribution of goods, images of trucks, trains, boats and planes crisscrossing the globe often come to mind. Certainly when you attempt to achieve large-scale distribution, the need to move goods across the globe becomes important. This kind of physical distribution is critical to many economic activities.

Overnight delivery services were largely unknown before the birth of FedEx. Yet it was an insight and an algorithm and its application to shipping that led FedEx to become a synonym for next day delivery. In his autobiographical account of starting up FedEx, Fred Smith explains how the algorithm he chose for distribution was central to his initial design for the company:

"My solution was to create a delivery system that operates essentially the way a bank clearinghouse does: Put all points on a network and connect them through a central hub. If you take any individual transaction, that kind of system seems absurd-it means making at least one extra stop. But if you look at the network as a whole, it's an efficient way to create an enormous number of connections. If, for instance, you want to connect 100 markets with one another and if you do it all with direct point-to-point deliveries, it will take 100 times 99-or 9,900-direct deliveries. But if you go through a single clearinghouse system, it will take at most 100 deliveries. So you're looking at a system that is about 100 times as efficient."11

The insight was the growing need to transport goods reliably overnight and the algorithm was this "spoke and hub" delivery system. The algorithm was not new, in fact Delta was already using it when FedEx was in its infancy, but it's application to shipping and next day delivery was new.12 For FedEx this algorithm served as their initial economic advantage.

Another example of algorithms and distribution improvements comes from UPS and their Right Turn Policy.13 UPS has always tried to optimize their delivery routes, but in 2005 UPS began the process of creating a new computerized route optimization system. This new system was in essence an algorithm that allowed for faster delivery of more packages while reducing costs. The new system generates delivery routes that do all they can to avoid left turns and the idling and waiting that accompany them. Ninety percent of the time, if a UPS truck is turning, it's turning right. For a company that delivers 15.8 million packages and documents around the world each day with a fleet of almost 100,000 cars, vans, tractors and motorcycles, this algorithmic improvement adds up.14

What have been the results of this optimization? In 2007 the algorithm removed 30 million miles off its delivery routes, saved 3 million gallons of gas, and reduce CO2 emissions by 32,000 metric tons, equal to removing 5,300 passenger cars from the road for an entire year.15

When it comes to distribution systems on a large-scale, the development and choice of algorithms have not only an economic impact, but an environmental one as well.

Consumption

It's hard to imagine now, but it wasn't long ago that searching for and gathering information involved travel, visiting libraries and other institutional records facilities. Google has changed all that, and at the heart of that change was an algorithm, namely PageRank.

It all began at Stanford in 1995. Larry Page and Sergey Brin met while Page was considering attending Stanford for his graduate degree.16 Part of their research was focused on a "web crawler" that would visit every web page it could find and begin to analyze the page and it's relative importance. The algorithm for determining a page's rank ultimately received the creative name of PageRank. By 1998 PC Magazine reported that Google "has an uncanny knack for returning extremely relevant results."17

How did this algorithm work?18 At the most basic level it would create a "citation graph" of the World Wide Web. Pages with more citations or links to it would be given a higher page rank. This idea was not new, but using web links and other web meta data and applying it to cataloging and judging the vast and growing data online was something new indeed.19

By August 1996, this research project part of the Digital Library Project in the Computer Science Department at Stanford had discovered roughly 75 million pages on the Internet and indexed about 30 million of them in a 28 GB database! It was obvious that the Google algorithm would need to be something that could deal with scale. This algorithm would need to deal with enormous amounts of data while still allowing instantaneous access to a constantly changing data set.20

This one algorithm solved a real problem: finding relevant information when faced with the information overload online. Word spread fast and soon almost everyone was going to Google to search the web. This presented an opportunity to sell contextual and relevant ads along with the search results and the rest is, as they say, history.

In Google's case, the PageRank algorithm is perhaps one of the most useful and lucrative algorithms in recent history, but it has not come without challenges. Google has had to constantly combat those who try to game the system for profit, using the fact that a system based on an algorithm, even a "smart" one, has inherent and repeatable weaknesses.

Googlebombing is when a person or group tricks Google's algorithm to return a certain search result. Since at least 1999 people have attempted to influence the ranking of particular pages in the search results returned by Google. My first experience with googlebombing was when I was informed that the top result for the search "more evil than Satan himself" was a link to Microsoft's web page.21 Google resisted manually tweaking these results citing the importance of the "objectivity" of the algorithm.22 In 2007 Google changed the algorithm so that this kind of thing was more difficult,23 but the economic incentive to be on the first page of Google's search results has continued to motivate determined hackers and business people alike.24 Search Engine Optimization (SEO) is the process of changing your website's data to improve rank and relevance in the Google search results.25 While there are legitimate ways to improve your rank, significant effort has been invested in finding ways to illegitimately place their website on the first page or top spot in the search results.26 Additionally Search Engine Optimization scams are prevalent. It is common for a business to pay a purported SEO company for a better page rank, often with little success.27

Clearly, Google's success shows that creation of a new algorithm for doing something that scales can be a critical part to business. Still, that was not enough. Google has had to continually adapt the algorithm to changes in the market. Perhaps this simply underscores the fact that the people who can invent, maintain and improve these algorithms are even more economically valuable than the algorithms themselves.

The Dark Side of Algorithms

"Not everything that can be counted counts, and not everything that counts can be counted." - Albert Einstein28

One of the great things about an algorithm is the fact that it is an "unambiguous sequence of instructions." This unambiguous nature allows for repeatability and scalability, but this very strength is also a weakness. Process patents, desirable as they are, often specify in clear terms what it means to follow the process and what it means to do something different and thereby avoid infringing on the patent. Since patents are public, you are in a sense giving the competition the map to the minefield! The other and perhaps larger weakness with algorithms is that there are qualities like style, judgment, understanding and creativity that simply resist being defined algorithmically.

Clearly employing repeatable and scalable processes to produce, distribute and consume goods and services is a boon economically, but there is a dark side to this specification and reduction of all things into a "sequence of unambiguous instructions for solving a problem."

Food

Consider your personal experience with food. Have you noticed a difference between homemade meals and those produced at a fast food establishment? If you have, you probably haven't noticed that the fast food was better. McDonalds famously applied for a patent with a 55-page description of a "Method and Apparatus for Making a Sandwich" underscoring their algorithmic focus to food production.29 While much of what has made McDonalds successful has been their focus on algorithmic repeatability, this has allowed for worldwide growth in scale, not deep improvements in culinary quality.

The quality of food isn't just in how it tastes, but also in how it helps us to stay healthy. Large-scale and efficient food production has been helpful in meeting the world's hunger needs, but along with the scale have come other problems. High output factory processes have created new risks for large-scale food-borne illnesses30 and high yield crops can generate food of decreasing nutritional value.31

The Unquantifiable

"The only problem with Microsoft is they just have no taste, they have absolutely no taste, and what that means is - I don't mean that in a small way I mean that in a big way. In the sense that they, they don't think of original ideas and they don't bring much culture into their product" - Steve Jobs, 199632

How does one define in systematic and unambiguous terms what is original, beautiful, stylish, elegant or even culturally valuable? Some things simply resist precise definition. Additionally, there is an economic reality that often good enough is sufficient, especially on a large-scale. One can be remarkably successful without these ambiguous and intangible qualities like beauty and elegance. Certainly Jobs' assertion that Microsoft lacks taste hasn't kept the company from being phenomenally successful. Indeed taking the extra time and money to push your work to the level of art can easily be considered wasted effort from an algorithmic efficiency point of view.

On the other hand consider Steve Jobs assessment of their "system" for developing innovative products:

The system is that there is no system. That doesn't mean we don't have process. Apple is a very disciplined company, and we have great processes. But that's not what it's about. Process makes you more efficient.

But innovation comes from people meeting up in the hallways or calling each other at 10:30 at night with a new idea, or because they realized something that shoots holes in how we've been thinking about a problem. It's ad hoc meetings of six people called by someone who thinks he has figured out the coolest new thing ever and who wants to know what other people think of his idea.33

For a company so often praised for style, beauty, innovation and elegance it's somewhat surprising that Apple doesn't have a system in place to ensure continued success along these lines. The reason for this omission is that creativity, art, style and beauty remain far outside the algorithm's grasp.

Banking

Perhaps nothing is more central to our economic system than banking. As banking operations have become more sophisticated and computer automated, the use of algorithms to make important decisions has increased.34

In the past, getting a loan meant a personal visit to a loan officer of a bank and an interview. Following the interview and documented analysis of income, the loan officer would discuss the loan with a loan approval committee and make the case for issuing the loan.35

Now, algorithms and risk probability models often replace this human factor. Is this better? The answer is complicated, but the underwriting of subprime loans for individuals and institutions that were unable to service the loan may not have occurred except for the powerful force of statistical algorithms and investment models suggesting it was a prudent course.36 These "bad loans" contributed to the housing bubble and the current US economic climate.37 We are now in the meltdown of the US residential real estate market and the beginnings of a commercial real estate depression.38 Perhaps there is room for more human judgment in banking loan decisions. This brings to mind what Warren E. Buffett said about the complex securities engineered by Wall Street mathematicians: "Beware of geeks bearing formulas."39

Problems of Scale

One reason to focus energy on algorithms comes from the problems associated with scale. When you grow the raw size of an organization or the customers you serve, algorithms can help you deal with that growth in a uniform way. On the other hand, this very growth can make it hard to focus. The reason that focus is often lost at scale is that a small percentage of a big number is still a big number! Even small problems are big problems when magnified by the sheer size of things. Focused efforts become more defuse, as almost any effort pales in comparison to the magnitude of the overall size of things. In this case, one's focus on size, algorithms and their efficiency are of utmost importance, but this comes at the cost of a host of smaller advancements which can be the seeds of real innovation.40

Sometimes limiting growth can help generate profit as you focus on quality or target your product effectively. Apple has done this recently with the iPhone. While many have suggested that Apple should focus on capturing market share, Apple has been focusing on profit-share. According to a recent report, Apple made $1.6 billion in operating profit off of the iPhone in Q3 2009. In the same quarter Nokia, made $1.1 billion, but consider this: Apple owns 2.5% of the cell phone market while Nokia controls about 35% of the market! Apple's focus is on a smaller sector of the market, but a sector where they can be focused and extremely profitable.41

Apple doesn't always play only for profit share. Certainly the iTunes Music Store is a market share leader, but there is something to be learned from growth through focus rather than scale. Apple's own iPhone App Store provides another example of large-scale and the challenges of "quality vs. quantity" that often come with it.42

Algorithms and Their Limitations

Thinking deeply about the core algorithms in your work can be very productive and help you gain a competitive advantage. Algorithmic complexity analysis can help you find areas where you can improve your economic returns significantly. Many great companies have at their core a collection of algorithms that form the engine of their success.

Algorithmic study makes the most economic sense on a large-scale but don't get caught up in the desire to scale. Sometimes the focus that is provided at small scale can allow you to produce things that would simply be impossible to produce in a large-scale environment. Asymptotic complexity is not everything! You can know how to do something extremely well and not be able to explain it or reproduce it at scale, yet it can still be very valuable. There are many important things that can't be succinctly described in an algorithm and this very fact may be your competitive advantage.

References

1 Levitin, Anany V. Introduction to the Design and Analysis of Algorithms. 2nd ed. Addison Wesley, 2006. Print.

2 For an introduction to Bubble sort see: Bubble sort. Wikipedia: The Free Encyclopedia. Web.

3 This number is very large. I used the command line tool bc, an arbitrary precision calculator, to calculate it and the result was a number 301,030 digits long! It would take 110 pages just to print this number.

4 This number is very, very large. It's so large, in fact, I'm not sure how to calculate it.

5 Definition of "economics." WordNet. Princeton. Web.

6 "Transcript of the Constitution of the United States - Official." Web. 5 Dec 2009. (see Article 1, section 8, clause 8)

7 "35 U.S.C. 101 Inventions patentable. - Patent Laws." Web. 5 Dec 2009.

8 "BENEFICIATION OF POTASH - Google Patent Search." Web. 5 Dec 2009.

9 Bessen, James, and Michael J. Meurer. Patent Failure: How Judges, Bureaucrats, and Lawyers Put Innovators at Risk. illustrated edition. Princeton University Press, 2008. Print.

10 Ibid.

11 Smith, Fred. "How I Delivered the Goods." Web. 5 Dec 2009.

12 "Online Extra: Fred Smith on the Birth of FedEx." Web. 5 Dec 2009.

13 "Right Turn at the Right Time - UPS Pressroom." Web. 5 Dec 2009.

14 "UPS Fact Sheet - UPS Pressroom." Web. 5 Dec 2009.

15 Right Turn at the Right Time

16 "Corporate Information - Google Milestones." Web. 5 Dec 2009.

17 "PC Magazine: Top 100 Web Sites (Google!)." Web. 5 Dec 2009.

18 For a deeper explanation of the algorithm see the patent: "Method for node ranking in a linked database - Google Patent Search." Web. 5 Dec 2009.

19 "Working Paper SIDL-WP-1997-0072." Web. 5 Dec 2009.

20 "Stanford BackRub Web Project." Web. 5 Dec 2009.

21 Sullivan, Danny "Google Bombs Aren't So Scary - Search Engine Watch (SEW)." Web. 5 Dec 2009.

22 "Official Google Blog: Googlebombing 'failure'." Web. 5 Dec 2009.

23 Co-written with Ryan Moulton and Kendra Carattini. "Official Google Webmaster Central Blog: A quick word about Googlebombs." 25 Jan 2007. Web. 5 Dec 2009.

24 "The Times (UK) Spamming Social Media Sites - Waxy.org." Web. 5 Dec 2009.

25 "Official Google Webmaster Central Blog: Google's SEO Starter Guide." Web. 5 Dec 2009.

26 "Derek Powazek - Spammers, Evildoers, and Opportunists." Web. 5 Dec 2009.

27 "Search Engine Optimization (SEO) - Webmasters/Site owners Help." Web. 5 Dec 2009.

28 Albert Einstein, a US (German-born) physicist (1879-1955). This quote is attributed to him because of sign that he had hanging in his office at Princeton.

29 "(WO/2006/068863) METHOD AND APPARATUS FOR MAKING A SANDWICH." Web. 5 Dec 2009.

30 Roberts, Paul. The End of Food. Reprint. Mariner Books, 2009. Print.

31 Pawlick, Thomas F. The End of Food: How the Food Industry is Destroying Our Food Supply--And What We Can Do About It. 1st ed. Barricade Books, 2006. Print.

32 Sen, Paul. Triumph of the Nerds. Ambrose Video, 2002. Print. Transcript.

33 "The Seed of Apple's Innovation." Web. 12 Oct 2004.

34 Kim, Jane J. "New FICO Credit Score Debuts." wsj.com 29 Jan 2009. Wall Street Journal. Web. 5 Dec 2009.

35 Clark, Kim B. Speech given at a City Club luncheon December 18, 2008

36 Coy, Peter. "Why Subprime Lenders Are In Trouble." BusinessWeek: TopNews 2 Mar 2007. BusinessWeek. Web. 5 Dec 2009.

37 "Declaration of the Summit on Financial Markets and the World Economy." Web. 5 Dec 2009.

38 Foust, Mara Der Hovanesian, Dean. "Why This Real Estate Bust Is Different." BusinessWeek: Online Magazine 5 Nov 2009. BusinessWeek. Web. 5 Dec 2009.

39 Lohr, Steve. "Like J.P. Morgan, Warren E. Buffett Braves a Crisis." The New York Times 6 Oct 2008. NYTimes.com. Web. 5 Dec 2009.

40 Weiss, David. "Impatience and Design by Counter Example" 6 Nov 2006. Web. 5 Dec 2009.

41 "While Rivals Jockey For Market Share, Apple Bathes In Profits." Web. 5 Dec 2009.

42 Gruber, John. "Daring Fireball: Pound the Quality." Web. 5 Dec 2009.

Since last year I've been working on several iPhone projects off and on. I have half a dozen solutions incubating that I think are both new and fun (and for problems where there isn't "an app for that" on the App Store. Don't tell Apple.) I've tried curtailing my blog reading, focusing only on "critical news" specifically to avoid reading about App Store rejections. Daring Fireball is one of a few blogs I still read daily and yesterday I read about yet another App Store rejection.

The Motivation and the Risk

As a software developer trying to start up a software company, reading these sordid tales is extremely demotivating. To be up against the raw market is risky enough, but to have to mentally grapple with the real possibility of some random reviewer's power trip banishing my months of design work to the bit bucket is unnerving to say the least. Unlike the fabled entrepreneur, I don't like risk, I seek at all times to reduce it as much as possible, but this is a show stopper kind of risk I don't know how to manage.

I've learned that I do my best work when doing something I'm passionate about, and I'm passionate about iPhone applications. It's what I want to do and the confluence of so many things I love. It's what I think about in my free time. It's how I want to create. But with all the App Store rejections, (and I'm sure there are more that have not been published) it's causing me to seriously question my development efforts. It seems like the only way to be sure you get in the App Store is to write a game, and even then not always. Now, I like a good game, but that's not the kind of solution I want to build. 

I hope to build apps that real people will be delighted to pay for and not dismiss because the price is more than $0.99. The consequence of this desire to build innovative and focused solutions that are worth more than $0.99 is that real investment must be made. Real money for design work, real money for development, real time spent understanding a problem space and building and testing the solution. From a realistic business perspective, can I really afford to invest that much time, effort and money in the hope that Apple will smile on me and I'll be able to make a living doing something I love?

The No Upgrades Business Model

One sure way to manage risk is to invest only a little at a time. Many developers release a small simple application to test the market and then make their livelihood on the upgrades over time of serving that portion of the market. On the iPhone App Store, there is no way to do this. Once you've purchased an App, you get upgrades to that application forever, for free. When modeling a business on the App Store this reality means you must amortize the life time cost of your development efforts over your predicted customer base. Not only is this tricky, but it makes releasing an application worth that price very difficult. Many of us have paid for years of Mac OS upgrades, and while it adds up to a lot of money, who would have paid over $500 for Mac OS X 10.0? I'm not saying that the iPhone business model is bad, but that it's different than the typical upgrade driven model. This difference affects the risk that a developer must assume and in most cases increases the risk, rather than decreases it. When you compound this risk onto the risk of an App Store rejection, it's no wonder that there seems to be a low price average on the App Store.

The Market

What frustrates me most about the approval process is actually not that it is so opaque, but that it does nothing truly positive for customers. It doesn't help quality. It doesn't help customers find the right solutions. It doesn't protect customers. As far as I can see, every part of the process is about Apple, their legal issues, their protection, their agreement with AT&T and others, and their success. I know there are more App's in the queue for the App Store now than ever before, but are they really compelling solutions? Some are, to be sure, but what about the rest? Isn't there a compelling business reason for Apple to support investment in valuable (not free) solutions built for the iPhone? They get 30% of the dollar applications as well as 30% of the 10 dollar applications. A percentage of a larger number is a larger number, last time I checked. At the scale of the App Store, Apple must see this in high contrast, black and white. Why fight against it?

The Trust Thing

It's about trust. Trust in developers and users. I think that's what grates the worst. It's as if Apple doesn't trust the developers to produce high quality applications or users to choose and rate apps appropriately. If Apple believed that the "unwashed masses" with iPhones could actually vote with their comments, their money and their downloads in some reasonable way, we'd be so much further along in this slow process of exposing simple and clear review guidelines. 

The Mac App Store

When the App Store first came out I was actually excited that perhaps someday there would be a similar store for the Mac. It would take so much of the upgrade, install and purchasing hassle out of the process. Now, I'm glad I have a "free" platform on which to fall back should the App Store process remain unchanged. If the Mac App Store resembles even slightly the unpredictable process of the iPhone App Store, I hope it never materializes.

Legal Issues

I recognize that there are real legal issues that Apple must deal with world wide. But like with the iTunes Store, deal with those legal issues so as to hide them from the customer without reducing the quality of the experience. Don't be so weak in bowing to the legal realities as to avoid seeking a real solution that makes the App Store a place where real software developers can invest. If all Apple wants is large numbers of applications for PR then they should drop the entry fee for joining the iPhone Dev program, but if they want something more, then they should act like it before and after they take the money.

Transparency

The review process can be a success without being transparent. The unpredictability is really the hardest part about the approval process. I don't believe the entire process needs to be fully transparent, as much as I'd like that. What really needs to be clear is how I can ensure that my application will be approved. If I have this assurance, then I can invest appropriately, until then, I'm gambling and that's no way to run a business.

Hope

I still have hope that Apple will change. They have in the past. I hope they do now, and soon. The iPhone is the best mobile phone platform out there, it's a shame to limit the creativity on the platform to what a $0.99 application investment can support. Dear Apple: Give us the rules, we want to play.

Fingerprint Biometrics

| 2 Comments

The other day I noticed one of my friends login to his laptop. I do this all the time, so that he logged in wasn't unusual, but how he did it, that caught my attention. He slid his finger on a small sensing area and after some delay he was logged in! No username and no password! This piqued my curiosity, put me on a research track. Here is what I discovered.

What are Biometrics?

When you login to your computer, security experts would say you authenticate. That is, you prove to the computer that you are indeed who you say you are. There are three ways you can normally prove who you are [2]:

  1. What you know
  2. What you have
  3. Who you are

When you login with a password, you are using the first form, what you know. If the password is kept secret and sufficiently hard to guess, when you enter your password the computer assumes it must really be you, because no one else would know the secret password. By this logic you are authenticated. There are other ways you can prove that you are who you say you are. When you purchase something with your credit card, or unlock your car door, you are normally authenticating with something you have. When someone checks your passport picture against what you look like, this is using two forms of proof: What you are, your face and what you have, namely the passport.

So what are Biometrics? From the word you might be able to deduce some of the meaning. The "bio" part means of or pertaining to biology. The "metrics" part relates to measurement. Put together biometrics it is the measurement of biological data. For authentication purposes a biometric is a physical characteristic that can be measured and then used to identify a specific individual.

When you use a "what you are" proof, it helps that you choose an attribute that is unique. If I used my height to prove that I am who I say I am, most of you would laugh. Why? Because there are lots of other people 6 feet 4 inches tall. For a strong identification, uniqueness matters.

How do fingerprint biometrics work?

Each fingerprint contains ridges in the skin which are detectable. These ridges make patterns which you can see with the naked eye. The ridge patterns can make loops, arches or whorls. In each fingerprint there are areas where one ridge changes, these points of change are called minutia. When a ridge ends, splits into two ridge, joins another ridge or creates a island; all of these features in a fingerprint are minutia. [10]

A fingerprint scanner detects the larger ridge patterns and records the following information about the minutia:

  1. Orientation - the direction the minutia is facing
  2. Spacial Frequency - how far apart specific features are located
  3. Curvature - the rate of orientation change
  4. Position - the (x, y) location relative to some fixed point

All of these can yield up to ideally 60 or 70 minutia for a single fingerprint. [10]

When a person first configures a scanner to use their fingerprint, this is called enrollment. This is a key time where strict process must be followed so as to avoid someone enrolling another's fingerprints as his or her own. In this process several fingerprints are recorded by the system and then an averaged template of the fingerprint is stored in the system. [10]

After enrollment, when a new fingerprint is supplied to the system, a statistical match is sought. If no match is discovered, the person is denied access. If a match is found, the person is granted access. Since biometric measurement can change slightly with each scan, determining a match is a probabilistic process. There is always a possibility that a valid fingerprint is rejected or an invalid fingerprint is determined to be good. [10]

What are the advantages and disadvantages?

To compare the relative merits of fingerprint as a biometric, we can considering the following properties of a good biometric [11, 6, 3]:

  1. Universality - each person has the characteristic
  2. Uniqueness - the characteristic is unique per person
  3. Permanence - characteristic remains the same over time
  4. Collectability - how easy is it to measure the characteristic
  5. Performance - accuracy, speed, and resource requirements
  6. Acceptability - culturally accepted by the population
  7. Circumvention - robust against fraudulent attacks

Universality

Fingerprints are largely universal. About 2% of the population can not use fingerprints due to skin damage or genetic factors.

Uniqueness

An important aspect of any biometric is that the characteristic be unique among all participants. Empirical evidence of fingerprints gathered since at least 1892, have found no two pairs of fingerprints that are identical, even between twins. [10] While this is reassuring, more recent research [13] indicates that the minutiae-based uniqueness as measured by fingerprint scanners may not be sufficient to determine individuality in every case.

Permanence

Fingerprints can be damaged and change due to manual labor or injuries.

Collectability

A key aspect of any biometric is the reliability of the measure coupled to the convenience of making the measurement. [10] Fingerprints are easy to collect and the systems today very inexpensive, around $20 per scanner if purchased in bulk.

Performance

Fingerprint recognition systems for large-scale deployments require a large amount of computational resources. For smaller populations the computational resources are smaller making this trade off allows for the current use in personal computers. Still compared with face recognition, for example, fingerprint scanners are more accurate, faster and require less computation and storage. Face recognition may seem very intuitive for humans, but the current mature computer systems are still far away from reliable face recognition in practice. [9]

Acceptability

Fingerprints are perhaps the most accepted biometric short of facial recognition. Still, the acceptance of biometric authentication technology depends on context, perceived benefit for the user and perceived privacy risks. [1]

Circumvention

Fingerprints are not impervious to attack, but using multiple finger scans can make the system harder to attack. ( see Myth Busters http://www.youtube.com/watch?v=MAfAVGES-Yc ) One method for improving the accuracy of biometric authentication systems is to enforce "two-factor authentication", that is one must authenticate by some biometric form as well as use a password or posses a token. [10] This additional factor can significantly harden the system.

Problematic Properties

Among the currently available biometrics, fingerprints have a large collection of positive characteristics. Some of the advantages of a biometric are that you don't have to remember passwords, don't have to worry about forgetting a password or smart card and it cannot be easily changed. [4] Because of these advantages systems have been developed for so called "One Touch Logon" [12] but in these systems one still makes significant trade offs between a password-based system and a fingerprint biometric based system. There are large trade offs between security and privacy [11] when using fingerprint biometrics.

Fingerprints have other problematic properties. They can be changed or damaged and some simply don't have fingerprints. Often because of these limitations fingerprint authentication systems have an alternate password based "back door" which can become the weakest link in the authentication system.

I think the biggest problem is that fingerprints are not very private, we leave fingerprints everywhere! Storing large amounts of fingerprint data in a safe way becomes a real challenge. If that data were exposed, criminals might devise a way to create fingerprints from the template data that fool fingerprint scanners. Biometrics in general are or can be unique identifiers, but they are not secrets. [7] Once a fingerprint is stolen, it's stolen for life! You can never get back to a secure situation! With a password or token system you can re-issue the token and invalidate the old token, or change the password. Not so with fingerprints! They are useful, but they are not keys. Keys need to be secret, random and easily updatable. Fingerprints are none of these things.

If fingerprint were to become the common authentication across different applications used for everything from logging onto your PC to accessing your bank account to opening your garage door, then value of stealing this information goes up significantly. At least with passwords you can spread the risk across different passwords for different services creating multiple barriers that must be overcome for full disclosure. With our fingerprints we have only ten of them.

References

[1] Heckle, R. R., Patrick, A. S., and Ozok, A. 2007. Perception and acceptance of fingerprint biometric technology. In Proceedings of the 3rd Symposium on Usable Privacy and Security (Pittsburgh, Pennsylvania, July 18 - 20, 2007). SOUPS '07, vol. 229. ACM, New York, NY, 153-154. DOI=http://doi.acm.org/10.1145/1280680.1280704 

[2] Guinier, D. 1990. Identification by biometrics. SIGSAC Rev. 8, 2 (May. 1990), 1-11. DOI=http://doi.acm.org/10.1145/101126.101127 

[3] Jain, A. K. and Ross, A. 2004. Multibiometric systems. Commun. ACM 47, 1 (Jan. 2004), 34-40. DOI=http://doi.acm.org/10.1145/962081.962102 

[4] Boatwright, M. and Luo, X. 2007. What do we know about biometrics authentication?. In Proceedings of the 4th Annual Conference on information Security Curriculum Development (Kennesaw, Georgia, September 28 - 28, 2007). InfoSecCD '07. ACM, New York, NY, 1-5. DOI=http://doi.acm.org/10.1145/1409908.1409942 

[5] Markowitz, J. A. 2000. Voice biometrics. Commun. ACM 43, 9 (Sep. 2000), 66-73. DOI=http://doi.acm.org/10.1145/348941.348995 

[6] Jain, A., Hong, L., and Pankanti, S. 2000. Biometric identification. Commun. ACM 43, 2 (Feb. 2000), 90-98. DOI=http://doi.acm.org/10.1145/328236.328110 

[7] Schneier, B. 1999. Inside risks: the uses and abuses of biometrics. Commun. ACM 42, 8 (Aug. 1999), 136. DOI=http://doi.acm.org/10.1145/310930.310988 

[8] Bergadano, F., Gunetti, D., and Picardi, C. 2002. User authentication through keystroke dynamics. ACM Trans. Inf. Syst. Secur. 5, 4 (Nov. 2002), 367-397. DOI=http://doi.acm.org/10.1145/581271.581272

[9] Zhao, W., Chellappa, R., Phillips, P. J., and Rosenfeld, A. 2003. Face recognition: A literature survey. ACM Comput. Surv. 35, 4 (Dec. 2003), 399-458. DOI=http://doi.acm.org/10.1145/954339.954342 

[10] Alfred C. Weaver, "Biometric Authentication," Computer, vol. 39, no. 2, pp. 96-97, Feb. 2006, doi:10.1109/MC.2006.47 http://doi.ieeecomputersociety.org/10.1109/MC.2006.47 

[11] Salil Prabhakar, Sharath Pankanti, Anil K. Jain, "Biometric Recognition: Security and Privacy Concerns," IEEE Security and Privacy, vol. 1, no. 2, pp. 33-42, Mar. 2003, doi:10.1109/MSECP.2003.1193209 http://doi.ieeecomputersociety.org/10.1109/MSECP.2003.1193209 

[12] Beomsoo Park, Sungjin Hong, Jaewook Oh, Heejo Lee, Yoojae Won, "One Touch Logon: Replacing Multiple Passwords with Single Fingerprint Recognition," cit,pp.163, Sixth IEEE International Conference on Computer and Information Technology (CIT'06), 2006 http://doi.ieeecomputersociety.org/10.1109/CIT.2006.128 

[13] Pankanti Sharath, Prabhakar Salil, Jain Anil K., "On the Individuality of Fingerprints (2002)," IEEE Transactions on Pattern Analysis and Machine Intelligence, http://biometrics.cse.msu.edu/cvpr2001_indiv.ps

Since the beginning of the Internet people have shared URLs with each other. Often the vehicle for sharing URLs was an email or a personal web page with favorite links. Today there are bookmarking websites where users share URLs, comment on them and rate them. [1] As the popularity of Twitter increases, more and more people are using Twitter to share URLs with each other. [2] The 140 character limit on communication with Twitter combined with the reality that many URLs are easily longer than 140 characters has given rise to more and more URL shortening services. While these services do a simple mapping, exchanging one short URL for a longer one, there are risks involved with trusting a third party to redirect you to a web page.

The basic idea for a URL shortening service is to exchange one URL that is short to another that is long. Typically the long URL is the desired destination. A person might send the short URL to a friend. When the short URL is clicked, the website looks up the longer URL and redirects the user to the longer URL. For example, suppose I just got an Amazon Kindle 2 and I wanted to share with my friends more information about it. Amazon typically has very long URLs. The URL for the Amazon Kindle 2 is as follows:

http://www.amazon.com/Kindle-Amazons-Wireless-Reading-Generation/dp/B00154JDAI/ref=amb_link_83624371_1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=0YPC2AH8155PQV3FWRPN&pf_rd_t=101&pf_rd_p=469942651&pf_rd_i=507846

That's 215 characters! I'll use this URL as the original URL with the following services to give you an ideas how they work:

bit.ly - http://bit.ly/

http://bit.ly/Z6eYE  19 characters

budURL - http://budurl.com/

http://budurl.com/bsfs  22 characters

eweri - http://eweri.com/

http://eweri.com/8rC  20 characters

hex.io - http://hex.io/

http://hex.io/ajz  17 characters

idek.net - http://idek.net/

http://idek.net/3kH  19 characters

is.gd - http://is.gd/

http://is.gd/lg7L  17 characters

lin.cr - http://lin.cr/

http://lin.cr/fvc  17 characters

POPrl - http://poprl.com/

http://poprl.com/Lm3  20 characters

snipurl - http://snipurl.com/

http://snipurl.com/cucc2  24 characters

tinyurl - http://tinyurl.com/

http://tinyurl.com/bngrky  25 characters

twurl - http://tweetburner.com/

http://twurl.nl/no316s  22 characters

urlBorg - http://urlborg.com/a/

http://ub0.cc/60/3G  19 characters

zi.ma - http://zi.ma/

http://zi.ma/65226b  19 characters

As you can see the original URL was 215 characters long, while the longest of the shortened URLs was only 25 characters long. I could post this shortened URL on Twitter and still have an expansive 115 characters left to comment on this URL. Perfect.

There are over 90 URL shortening services available online. A more complete list of URL shortening services is located at http://mashable.com/2008/01/08/url-shortening-services/.

Trusted or Untrusted

The most obvious risk associated with URL shortening is that it's difficult to know where the URL will take you, until you click it. The true destination of the URL is opaque. Often when I receive a dubious link via email, I hover my mouse over the URL, or view the HTML source to discover the real URL destination address and evaluate if I trust it enough to click. With a shortened URL, it's hard to know where it will take me, until I click it. Email Phishing scams are using URL shortening service for this very reason. [7]

Another problem with URL shortening is how it interacts with filters. A spam filter could use the URL in the past as one more hint that the email could be nefarious, but with a URL shortening service as the broker of URLs, the filter can't make any judgment about the URL. Many URL shortening services take spam complaints and will disable URLs if they are discovered to point to spam websites. [3] Some also proactively search their URLs for blacklisted websites and remove or disable these shortened URLs. [4]

Not just spam filters can be bypassed. Both Firefox and Google Chrome web browsers use Google Safe Browsing [5] a feature with warns users of malware or phishing sites. In the past using a shortened URL, instead of getting a warning message, users are sent directly to the dangerous web page. [6]

Less serious, but still problematic is using URL shortening services to hide the motive for an online review or recommendation. A seemingly objective review is tainted when readers discover that the author gets a monetary kick back for sending people to the reviewed product's site. Since shortened URLs hide the real URL they can be used to hide affiliate URLs and surreptitiously link to online stores. Most affiliate URLs are easy to spot, but when wrapped in a shortened URL, detection is more difficult. [8]

Another more remote, but still plausible problem with URL shortening is that should a URL shortening service become compromised, hacking one site would allow for redirecting popular shortened URLs to phishing or malware sites.

Getting More Transparent

Many URL shortening services have added some level of "see before you click" functionality. For example, any tinyurl can be prepended with the text "preview" in the URL and it will not redirect, but show the destination URL for inspection at tinyurl.com. Take the tinyurl above

http://tinyurl.com/bngrky

and modify it as follows:

http://preview.tinyurl.com/bngrky

While this adds characters to the URL, it allows the user to evaluate the URL before redirecting to the site. BudURL has an even more compact preview function. Just adding a '?' to the end of the URL will turn it into a preview URL.

http://budurl.com/bsfs  will auto redirect to the original URL

http://budurl.com/bsfs?  will preview the link first

Some of the services provide a little popup window that displays a picture of the webpage when you hover over the URL link.

Conclusion

A hacker or spammer is empowered by using a "benign" URL shortening service that everyone uses and everyone trusts. Once the click is made, a homographic attack may follow and will make it very difficult for a normal user to detect that they are being redirected to a phishing site. The real danger is that people have become habituated to trusting unknown links from their friends. This is dangerous because if their friend's account is compromised, it might not be their friend sending a link and the shortened URL will be clicked without concern.

An example of this propensity to click occurred 12 Feb 2009. One of my friends tweeted, "Don't Click: (link)". I was curious, but I didn't click the link. Next another posted the same thing, than another! It seemed fishy to me, and I later found out that the link presented a web page with another button that said, "Don't Click!" Naturally curious people, and trusting in their friend's recommendation, clicked the button and all of the sudden they noticed that they had in fact tweeted the same link though they never consented to doing so! It was the first socially engineered twitter virus. [9] While this virus was started as a joke, it spread extremely fast. [10] Luckily this social virus was harmless, but it reinforces how effective a socially engineered virus can be.

There are always trade off decisions to be made. In this case, the trade off is between the convenience of a short URL and the need for disclosure of a URL's destination.

References

[1] Tony Hammond, Timo Hannay, Ben Lund and Joanna Scott. - Social Bookmarking Tools (I): A General Review In: D-Lib Magazine 11, Nr. 4, 2005 http://www.dlib.org/dlib/april05/hammond/04hammond.html

[2] State of the Twittersphere - Q4 2008 Report - http://blog.hubspot.com/blog/tabid/6307/bid/4439/State-of-the-Twittersphere-Q4-2008-Report.aspx

[3] is.gd - Technical Information - http://is.gd/tech.php

[4] SURBL http://www.surbl.org/

[5] Google Safe Browsing for Firefox BETA http://www.google.com/tools/firefox/safebrowsing/  

[6] Finjan's Malicious Code Research Center, Evasive URL techniques, 25 Jan 2009. http://www.finjan.com/MCRCblog.aspx?EntryId=2153

[7] McGrath, D. Kevin, Gupta, Minaxi. Behind Phishing: An Examination of Phisher Modi Operandi. https://www.usenix.org/events/leet08/tech/full_papers/mcgrath/mcgrath_html/mcgrath_gupta.html

[8] Parker, Ryan J. Shortening (Affiliate) Links For Prettier Linking. 20 Feb 2007. http://www.ryanjparker.net/shortening-affiliate-links-for-prettier-linking/

[9] Korben. Petit cours de Twitt Jacking :-). 30 Jan 2009. http://www.korben.info/petit-cours-de-twitt-jacking.html

[10] Johnson, Clay. What is this Don't Click business? 12 Feb 2009. http://sunlightlabs.com/blog/2009/02/12/what-dont-click-business/

Creative Desires

| 0 Comments
After reading Michael Lopp's excellent post The Makers of Things referencing the construction of the Brooklyn Bridge I was reminded of a poem. Not coincidentally, it's named The Bridge Builder and while I've mentioned it before, I think it bears repeating.

The Bridge Builder
by Will Allen Dromgoole

An old man, going a lone highway,
Came, at the evening, cold and gray,
To a chasm, vast, and deep, and wide,
Through which was flowing a sullen tide.

The old man crossed in the twilight dim;
The sullen stream had no fear for him;
But he turned, when safe on the other side,
And built a bridge to span the tide.

"Old man," said a fellow pilgrim, near,
"You are wasting strength with building here;
Your journey will end with the ending day;
You never again will pass this way;
You've crossed the chasm, deep and wide-
Why build you this bridge at the evening tide?"

The builder lifted his old gray head:
"Good friend, in the path I have come," he said,
"There followeth after me today,
A youth, whose feet must pass this way.

This chasm, that has been naught to me,
To that fair-haired youth may a pitfall be.
He, too, must cross in the twilight dim;
Good friend, I am building this bridge for him."

What I like most about this poem is that it touches on a reason we do the things we do. For example, when Washington Roebling became bedridden, why did he keep running the project rather than hand off the job to another? What was his motivation to carry on? We may never know, but for each of us, we can know our desires, our reasons. This is especially important because in the end we will get what we desire.

There are perhaps as many different motivations as there are people. Since we are complex beings, there are probably a multifaceted set of reasons behind our thoughts and actions. More subtle still, one reason may not even dominate in each context, every time. Some might work for a reward in money or fame. Others might do the things they do to impress others or to be a part of the "cool crowd". The desire to be well liked can be a powerful motivation for great effort. Some might create simply to provide for their temporal needs and for no other exalted reason. For them, the work they do is simply avoidance of pain. Others still create out of a sense of duty to their family, friends or traditions. Some simply want to see that they can do something and take joy in finishing a task well done. While some might laugh, others do the work they do out of a sense of love, a genuine desire to help. For me, when someone creates something, anything, it is always wonderful, but more impressive, are the reasons coupled with the creation. 

Another aspect to creative motivation is that different desires yield different results and staying power. When you are called to lead a team, (or more difficult lead yourself alone) to work through the impossible, you can not be ignorant of the motivations needed commensurate with the work at hand. However, discerning these delicate human desires and their creative force can be a powerful tool when confronted with the problems and setbacks that will undoubtedly come.

Ultimately we choose. We choose to build, to create, to do the things we desire. We make the little choices, as small as lifting a bucket full of mud from a river bottom and as large as trusting that a bridge pier will stand the test of time. Small and big and everything in between reveal in us our inner creativity and deepest desires. Recognizing this brings a somber circumspection to the tasks of each day. The wonderful thing is that it's all in there, in each of us, to quote, "Trust me when I say that I can close my eyes and see the end result, and when you can see it, too, you will be amazed."

Specifying Performance

| 7 Comments | 0 TrackBacks
When you design a software product or feature you need to consider not only what the software will do, but also how it will interact with the user. The functional requirements for the software typically refer to what the software does. Nonfunctional requirements clarify the parameters for how the software will meet the functional requirements. Common nonfunctional requirements include things like reliability, availability, security, safety, usability, programmability, maintainability and performance. All of these are important, but your software's performance will have a disproportionate impact on how your software will feel when people use it. I think Apple put it well in their Apple Human Interface Guidelines:

"Performance is the perceived measure of how fast or efficient your software is and it is critical to the success of all software. If your software seems slow, users may be less inclined to buy it. Even software that uses the most optimal algorithms may seem slow if it spends more time processing data than responding to the user. ... Remember that the perception of performance is informed by two things: The speed with which an application processes data and performs operations and the speed with which the application responds to the user." [1]

While performance is one of the most important nonfunctional requirements, it's often the most difficult to define. For new features it's difficult to know where to set the performance goal because there's not always some similar functionality to compare it against. Further, how would you define "slow" or "fast" in an objective and verifiable way? Confronted with this problem most software engineers simply skip this section of requirements with the justification, "If it's too slow, I'll see it and we'll fix it then. I know slow when I see it." If performance is specified, often some arbitrary time limit is set with little reasoning behind the performance goal.

Failing to specify reasonable performance requirements makes it very difficult to verify that your software is actually meeting your users' performance expectations. And what are these user expectations any way? How can you determine what makes one piece of software fast and the other slow? Understanding a little about the psychology of time perception can answer these questions. Armed with this understanding you can specify, design and build for performance from the very beginning and this tremendously improves the chances of a high performance solution. 

Responsiveness

Any human computer interaction can be thought of as a conversation between the human and the computer. The user does something and the software and hardware respond to that request. The time it takes the system to respond to the request of the user is the system response time.

There as been quite a bit of research done in the area of system response times. In 1968 R. B. Miller wrote a paper titled "Response Time in Man-Computer Conversational Transactions." [2] The Department of Defense created MIL-STD 1472F [3] a 219-page document titled "Department of Defense Criteria Standard: Human Engineering (revision F)" which describes many of the non-functional requirement standards for use in the military. Sponsored by the US Air Force the MITRE Corporation published in 1968 a document titled "Guidelines for Designing User Interface Software". [4] In 1996 the Department of Defense created an eight-volume work entitled "Technical Architecture Framework for Information Management (TAFIM)" and the last volume in this work includes guidelines for response times [5].

All of these standards for system response times include descriptions of types or classes of actions by the user and the guidance for the acceptable response time by the system. More recently Steven C. Seow published a book titled "Designing and Engineering Time". [6] This excellent book describes in detail some of the important considerations for defining appropriate response times and simplifies the combined recommendations of previous research into a simple framework. The general framework Seow suggests is as follows:

Instantaneous (0.1 to 0.2 seconds)
Immediate (0.5 to 1.0 seconds)
Continuous (2 to 5 seconds)
Captive (7 to 10 seconds)

You use these performance guidelines by asking yourself the question: For this feature, what is the users expectation for response time? Is the user expecting an instantaneous response? If so, then you know your software should respond within 0.1 to 0.2 seconds.

So what is slow? These response time categories provide a powerful answer to this question. Slow is when a user expects an immediate response, within 0.5 to 1.0 seconds, and they get a continuous response, somewhere from 2 to 5 seconds! Slow is when a user expects an instantaneous response, within 0.1 to 0.2 seconds, and they get an immediate response, somewhere from 0.5 to 1.0 seconds!

Note: Can a response be too fast? Yes, a good example of this too fast response is when a user starts a software installation and the install completes immediately. The reality of the response time doesn't conform to their expectation and will cause the user to think the install didn't work properly.

Performance is a perceived reality based on the conversation between the human and the computer. As Qui-Gon Jinn said to Anakin, "Remember: Your focus determines your reality." [7] This is especially true with software performance. What the user is focused on is not the performance of your application, at least not initially. They are focused on doing something with your application as the means to an end. When the application is responding to their commands appropriately, this becomes a natural conversation between the human and the computer and turns into a state of flow where the user is happy and productive. The challenge for a software developer is to maximize the probability that your software will disappear from the focus as they are enabled to enter that zone of creativity. Response times that are too fast or too slow and disrupt the user's state of flow degrade the user experience.

Sadly, brilliant architecture doesn't matter if the user feels like you're wasting their time or something is wrong. They will feel like something is wrong if you don't ensure that the system responds within the expected time frame. Identifying the areas in your software that conflict with a user's expectations is the first step in making your software feel fast and responsive. Putting the user at the center of this question is the key to building high performance software. Let's dive in to what each of these response time categories means in detail.

Note: Steven C. Seow has long studied the distortion of time perception. I met him shortly after he joined Microsoft. Recently he has released his first book, "Designing and Engineering Time". It's a fantastic book, one I own and highly recommend. While I try to summarize some of his ideas on responsiveness, he goes into much more detail in his book and I recommend going there for a more complete understanding.

Instantaneous

When a user moves a mouse or clicks a button the expectation is that the software will respond instantaneously, that is at least within 0.1 to 0.2 seconds. The easiest way to determine if a part of your software falls into this category is if the interaction mimics some object in the physical world that also has an instantaneous response. Most forms of user input fall into this category. Clicking a menu and waiting for it to drop down or dragging a slider are all examples of where an instantaneous response is expected. If you have ever opened your Mac laptop from sleep, and tried to click the Airport menu and had it hesitate and then display, you have experienced the problem where the expectation for an instantaneous response is not fulfilled.

Immediate

The best example of an immediate response, between 0.5 and 1.0 seconds, is scrolling a window. The user's mental model is that the data has already been "loaded" so telling the computer to display a different section carries the expectation that it should occur immediately. The detailed operations behind any user interaction are hidden from the user. For example, fetching and rendering large documents often involve paging in and out memory, but this is invisible to the user. When they move to the next page they expect the response to be immediate since their mental model tells them all the "hard work" as been done when the document was first loaded. The expectation is what matters. In this realm of response times, the key is to communicate to the user that the request or command has been received and if the action is simple, a complete response is returned in less than 1 second. Animation can go a long way in avoiding awkward pauses in the response between the system and the user. The iPhone's checkered back screen when scrolling a web page is a good example of immediate feedback, while dealing with real hardware and software constraints.

Continuous

Unless the user is expecting an instantaneous or immediate response there is generally recognition that the computer needs to "think" about doing stuff. Miller wrote:

If you address another human being, you expect some communicative response within x seconds-perhaps two to four seconds. ... In conversation of any kind between humans, silences of more than four seconds become embarrassing because they imply a breaking of the thread of communication. [2]

In the continuous category, between 2 and 5 seconds, it can be helpful and calming to let the user know that the computer is "thinking." Progress bars are often helpful in this case, but not required. On the Mac, both Keynote and PowerPoint use progress bars to inform the user that work is being done when loading documents. When the user asks your software to do something moderately complex, the continuous response will be the expectation.

Captive

In the 7 to 10 second response range, users need to see real progress and visual response. I like to think of this as the captive audience range. You will have a user paying attention to what's going on in this range, but anything that takes longer than this, they'll move on to something else and come back to see progress later. A good example of this is downloading a fast start movie online. The user's attention span is about 10 seconds, so if your process takes longer than that you'll need to provide significant visual feedback to what's going on and be certain to give the user the ability to move on to other things.

The Process of Setting Performance Goals

For each user interaction in your software ask yourself if the user is expecting an Instantaneous response, (0.1 to 0.2 seconds) an Immediate response (0.5 to 1.0 seconds) a Continuous (2 to 5 seconds) or a Captive response (7 to 10 seconds). This will set the range of response times for that part of the system. Use the appropriate response time range as your performance goal. This will give the developer a basic understanding of where the performance for that feature needs to be and allow the tester to test for system responsiveness from the beginning.

Most features are easily classified into one of the four categories, but sometimes it's hard to tell. In this case usability studies can help inform you if your best guess was wrong. 

Conclusion

When you need to choose which part of your application to focus on speeding up, understanding where and why users will perceive performance problems is key. You can't and shouldn't optimize everything. Remember, perception is reality. No mater what your metrics say, if the user thinks your application is slow, it is.

Objectively measured durations don't mean anything without a corresponding benchmark that shows what a user expects. They will judge your software against their expectations. You need to identify what kind of expectations the user has for each stimulus and response in your application and make your software response times meet these expectations. Users have four general categories of expectations: Instantaneous (0.1 to 0.2 seconds), Immediate (0.5 to 1.0 seconds), Continuous (2 to 5 seconds) and Captive (7 to 10 seconds). The more areas in your application where the users expectation are met with your application's actual response the faster the application will feel.

Maister's First Law of Service [8] states that the key to satisfaction is the delta between what was expected and what was perceived. If the perception is that your software performs better than expected, satisfaction will be high, but if the perception is that your software performs worse than expected, satisfaction drops. Perceived durations and actual durations along with an understanding of the users' tolerance for both will allow you to carefully design software to meet and exceed user expectations.

References

[1] Apple (2008). Apple Human Interface Guidelines. Available online at http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/OSXHIGuidelines.pdf page 31, 57

[2] Miller, R. B. (1968). Response time in man-computer conversational transaction. Fall Joint Computer Conference U.S.A. 267-277.

[3] Department of Defense Design Criteria Standard: Human Engineering. MIL-STD 1472F. Available online at http://hfetag.dtic.mil/docs-hfs/mil-std-1472f.pdf

[4] Smith, S. L. and J. N. Mosier (1986). Guidelines for Designing User Interface Software: ESD-TR-86-278. Bedford, MA: The MITRE Corporation.

[5] Department of Defense Technical Architecture Framework for Information Management (TAFIM). Volume 8: DoD Human Computer Interface Style Guide.

[6] S.C. Seow, Designing and Engineering Time: The Psychology of Time Perception in Software, Addison-Wesley Professional, 2008.

[7] Star Wars - Episode I, The Phantom Menace, 20th Century Fox, 2005.

[8] Maister, D. H. (1985). The psychology of waiting lines. In Czepiel (Ed.), The Service Encounter. Lexington, MA: Lexington Books. 113-123.

Google Chrome and Gears

| 16 Comments | 0 TrackBacks
Google is now building their own web browser named Chrome, based on the WebKit rendering engine and a beta version for Windows is currently available. They've put up some great comics that do a great job of introducing the new browser and some videos explaining some of the changes they've made.

I've always found Google applications on my Mac to be a bit out of place. Maybe it's part of the design they are going for, but even today, when I use their online apps, like Gmail, or desktop applications like Google Earth, they work well, but beautiful they are not. They are blocky, text heavy, lowest common denominator type of UIs. It's always felt to me like they didn't quite "get it" when it comes to blending into the platform and learning to be a "good citizen" on the user's platform of choice.

Today, it's clear to me why I've felt this way: Google isn't interested at all in "being a citizen" or part of a platform, they are interested in being the platform. If you look at the way Chrome is designed, it's not so much designed to be a good browser, as much as it is a good operating system for web applications. Google's desire is very much the same as Microsoft's, except abstracted a little higher up the stack. They want to own the platform upon which web applications are built, just like Microsoft wants to own the platform upon which desktop applications are built. This game of disintermediation seems to never end, but this time, what can Microsoft do? Or anyone else for that matter?

This is not to say that Google's success criteria for Chrome is market share. I think what they are trying to do is have a more direct hand in guiding and shaping the web app platform and raising it to a level that best fits their desires and needs. Google will be successful if in the future developers see no downside to developing a web app versus a traditional desktop application, but in-fact see a sizable upside to taking the web app route. For end users success will be when the "Omnibar" becomes the default interaction mechanism, the place they go to first and installers become a thing of the past.

Maybe that's why I think Google's stuff looks kind of basic. They are to the current web platform what command line terminals were to the earlier personal computer platform. The basics, from which great things are built.
Everyone knows that the iPhone is an expensive bit of technology, but overall its success has shown that it's "worth it" in most places. What's interesting is that the iPhone is NOT having much success in India, where the monthly payment can't hope to subsidize the costly phone. Says Niti Bhan:

I'll say it again about the iPhone, business models need to be designed as much as the product for the market they are intended to operate in, taking the nuances of culture, socioeconomic development as well as the customer's mindset into account. That is, as Neelakantan puts it so pithily in his most recent comment, "know your customer" and that's something we know that Apple hasn't quite managed to do yet. After all, their design success is primarily through designing for themselves.

Having the same marketing story for every market world wide certainly has its advantages, but perhaps there's room for some diversity here. Then again, Apple may have its current focus on affluent markets and plan to customize and optimize things later.

Painted on the Inside

| 1 Comment | 1 TrackBack
LegacyFlightMuseum.png
My son and I recently visited the Legacy Flight Museum in Rexburg, Idaho. This is an aviation museum that they call a "living museum" because everything on display actually flies regularly! In fact, we see them flying over our house on a weekly basis.

LegacyFlightMuseumBillboard.png
When we entered the office area of the hanger to start the guided tour, I saw a large table full of model airplane parts, plans, glue and paints.

ModelAirplaneTable.png
The museum is open 9 AM to 5 PM, Monday through Saturday in the summer, even so, there are times when there are no visitors. During the down time some of the curators and tour guides build model airplanes. When we were there, we met one of them, his name was George Howard. After the tour, I asked him about his hobby, and he showed off his model airplanes.

SmallerPlanes.png
He had a P-61 Black Widow, a B-25 Mitchell, a B-17 Flying Fortress, a B-29 Superfortress, a Convair B-36 as well as many other smaller fighters and planes whose names I don't remember. It turns out he teaches model building classes in the museum from time to time. You could tell by talking to him that he loves the planes. While we were talking about the models, he said this, "If you'll look into the cockpit, you can see the dashboard is all painted. Every plane is like that, even at 1/32nd scale. The propellers all work, and the wheels on the landing gear work and even the ordinance hooks release." Gingerly putting down one of his prized planes he picked up the B-29 Superfortress and continued, "This plane has an office and bunks and they're all painted on the inside, if you could see them, you'd see all the detail. You know when you start cutting corners, who knows where you'll stop? I try to go all the way."

BlackWidow.png
Bombers.png
This idea of doing something "on the inside" bespeaks a level of integrity and love for quality work that is rare in any line of work, but especially in software. The counter arguments abound: Why the extra time and effort? Why should we be doing something that will seldom if ever be seen or appreciated by the end user? Where's the customer use case? What's the business case? Who cares? How will this really make a difference for the customer? Like painting on the inside of a model airplane, the answer is, of course, that they will not know, but you will. As the builder, designer and developer of the product, you will know that it's painted on the inside.

Clockwork

There's a long tradition of quality that can't be seen with time pieces, especially small ones. If you have ever opened a clock, or observed as an expert watchmaker opened the case, you know of the intricate gears and precise beauty inside. While the watch cover almost always conceals this internal and hidden quality workmanship, it was seen by enough people that it became the common standard for exact, reliable and good engineering. People would say a system was good when it "worked like clockwork." Some modern clock manufacturers have chosen to put on display the internals of their clockwork. This is an interesting way to allow the user a window into the complex and detailed world of gears, springs and latches that make the whole product work.

Regulateur.png
Tourbillon.png
Now, one might again argue, "Where is the user scenario? How does this actually make it better for the user? But, of course, there is no user scenario. Functionally, the clock is the same with or without the glass panel. One might even argue that with the gears exposed it is harder to read the time! But the feelings of the user about the purchased piece of engineering are much, much different. There's a feeling of trust that someone took the time to make all of those inscrutable pieces fit together and work so that he or she could do something rather simple, like keep track of time. There's also a sense of pride in owning such a fine bit of complexity.

My favorite "marketing use" for this kind of watch is where the manufacturer has put the window on the back of the wrist watch only. This way the watch looks normal in every other respect, except when the user puts on the watch or takes it off. If someone comments on the watch, there's a natural path for the owner to say, "Thanks, but look at this..." and pull off the watch and show all the insides clicking and moving just like, clockwork. "Cool huh?" "Yeah, it's beautiful."

The integrity of design and beauty was always there. Functionally, there is no new "feature" in the watch. But if you call love for the product and desire for superb quality, inside and out, a feature, well then, this kind of product has it.

Trophy Box

This kind of care for the inside and unseen workings applies just as much to what you do as to how you do it. For as long as I can remember, part of the tradition for shipping software at Microsoft has been that you get a "Trophy Box" or a copy of the shipping software, in the shrink wrap for you to use or just keep on display. Many at Microsoft would simply keep each one of these on a shelf over time accumulating physical reminders of products they had helped to produce. This tradition was followed for Mac Office 2008 as well, but for the first time in MacBU history it was different:

OfficeSpecialLaunchEdition-Spine.png
The Mac Office 2008: The Special Launch Edition

OfficeSpecialLaunchEdition-Front.png
The front of the box

OfficeSpecialLaunchEdition-Back.png

The back of the box

NoteFromCraig.JPG
Craig's Note

InnerSleeve.JPG
The inner sleeve

TheOfficePen.JPG
The Office Pen: Proof that MacBU has produced multi-touch hardware. ;-)

NiceTouchWithOfficeLogo.JPG
Nice touch on the Office logo.

CDSleeve.JPG
Not just Office, but Expression Media too!

TheCDs.JPG
The CDs: Nice "ether" swoosh stuff, eh?

EtchedShipDate.JPG
Nicely etched Office ship date on the back of the box along with the edition number.

ExactlyTheRightNumberOfStickies.JPG
The correct number of Stickies! Well played!

Now, no one in MacBU will deny that the Office 2008 product cycle was a tough one, and a box like this in no way makes up for all the difficulties. Certainly it doesn't "help sales", but it does mean something to those on the inside. It says something to the employees, who are your first customers. It says, "You're worth taking a little extra time and a little extra care." This kind of message may not be something accountants can tabulate in the asset column, but its value is there just the same.

The Apple Paperclip

A few months ago, my wife's iPhone stopped working. We called Apple and since we were nowhere near an Apple Store the lady on the phone said she would send us a box to send the iPhone back to Apple for repairs. This kind of process, while less ideal than dropping the phone off at an Apple Store and walking out with a loaner phone, is something I've come to expect from Apple's customer support. When we got the box here's what it looked like:

TheBox.png
The iPhone repair box we received.

TheOpenBox.png
Simple directions on the lid of the box

3Steps.png
3 steps: Help is here. Back it up. Pack it up. Note to Apple: Apology accepted.

InstructionManual.png
The "iPhone Service Guide", step 1: Don't lose this.

TheiPhoneBox.png
The Real iPhone repair box.

PaddedThenRepaddedBox.png
The white box is padded, with a padded sleeve for the iPhone. And tape.

FoamCaseWithTape.png
The foam case. The red stripe removes to expose adhesive for the flap.

TapeForBox.png
Tape strips for closing the box included.

Let me review the situation: Apple sends a box with thick foam padding and return postage paid to send your iPhone to Apple to repair. General overview of the process, backup and packing is provided, as well as detailed instructions. Inside the thick foam is another box, also with foam padding, and inside this box is a foam sleeve with a flap to fully surround your iPhone with protective padding for the trip. Tape is included so you don't even need to find packing tape to get the job done!

Look at all the padding and packaging there to protect your precious iPhone! What does it say to you as the customer about how Apple feels about your iPhone? What does that say to you about how important your iPhone should be to you? But the most distinctly "Apple touch" in the whole package is the Apple SIM Ejector Tool that is included:

AppleCertifiedPaperClip.png
An individually packaged paperclip! Did they need to do that? How much did that cost them? Couldn't they just trust that folks could find a paperclip around the house or office? Yes they could have, but they didn't. With the desire to make the the whole process as painless as possible they made a negative repair experience into a positive, brand building and trust building one.

I'm sure there are other examples, but it's this care for the little details, things on the inside, bits that are often unseen, that can really make a difference both for you as the service provider and as the customer receiving the care. When someone buys a product, it's partially about the cost and the feature set, but for your best customers, it's also about buying into the person on the other end of the transaction. Having the integrity to keep things "painted on the inside" really matters in the long run, because eventually it shows. You can't hide it. Eventually, it will get out and when it does, it will define for others who you are.

Most importantly, however, long before anyone else will know, you will. You can go on putting "lipstick on a pig" for a long time and be successful at it, but from the beginning you'll know and that will effect the way you treat the product and treat yourself. I'm not suggesting everything you do must be perfect, but it really needs to be your very best. You could be doing your very best and still be unsuccessful in a myriad of ways, but it's much easier to learn from your mistakes when you can look back and honestly say, "Well, I did the best I could." Additionally, there's something very peaceful and happy about doing great work, even if it's only great for you. The alternative is in my mind untenable because, "You know, when you start cutting corners, who knows where you'll stop?"