In a comment on my last post, Matt asked several exceedingly thought-provoking questions. I was going to respond there, but I had too many thoughts for a single comment. I had to take off my hat because I was getting too warm while thinking about this…

Ah, but what to pick, Mr. Panozzo? The road less taken? The thing that you love? The thing that really could work? The thing you can make a living at? The thing you’re rather disinclined toward but you’re good at and know will have the greatest impact?

Knowing you can pick a couple, sure, but you yourself admitted to 500 possibilities. Maybe one of each, or something that answers more than one question?

What’d you pick?

These deeply resonated with me, as I have thought along similar lines. As an example, in October in some personal notes I wrote the question “What is the highest good man can accomplish?” It seems like some of the questions were along these lines, asking what is the best or highest thing that one can aim for. Can you make the best impact doing something that you are especially predisposed to do, or something that you really just want to do?

As far as “what’d you pick”, I’m not sure if this should expand to “what would you pick” or “what did you pick.” Either way, haven’t quite gotten there yet. :) I’m still exploring these questions myself. With that said, I don’t have answers, but here are some thoughts.

Viewing the questions and possible answers through the lens of existentialism applies almost perfectly here. There is the knowledge that you have limited time and that ideas cannot be implemented without using some of it. There is uncertainty in the value of a decision. What will it will be worth to you, and what will it be worth to other people? What are your weights for these values? There is angst because you realize that you are absolutely free to choose.

Glancing through the Wikipedia article on existentialism, I saw this quote by Kierkegaard, who is generally considered the father of that branch of philosophy. He is a religious existentialist, so you can read it through that filter. In an early writing to another thinker, he writes:

What I really lack is to be clear in my mind what I am to do, not what I am to know, except in so far as a certain knowledge must precede every action. The thing is to understand myself, to see what God really wishes me to do: the thing is to find a truth which is true for me, to find the idea for which I can live and die. … I certainly do not deny that I still recognize an imperative of knowledge and that through it one can work upon men, but it must be taken up into my life, and that is what I now recognize as the most important thing.

I see this as an extremely pertinent comment. Essentially he is saying that he can have knowledge of anything that he desires, but the real challenge is to ascertain is the highest value, ideal, or idea that he can live for. It’s not what he wants to know, but rather what he wants to do with his life. If he knew what to do, he could quite easily figure out what he needed to know to do this. However, only by knowing himself can he know how to live, and only by living can he know himself. Hence the paradox, as I see it. He says that whatever he recognizes as true knowledge must be taken up into his life, which is to say that he must live it.

I came across this gem about existential thoughts. I highly recommend reading the whole thing. Several things that I have previously thought about were contained in it. It’s pretty short and understandable, but one thing that really home with me were the following paragraphs:

When gifted children try to share [existential] concerns with others, they are usually met with reactions ranging from puzzlement to hostility. They discover that others, particularly of their age, clearly do not share these concerns, but instead are focused on more concrete issues and on fitting in with others’ expectations. Often by even first grade, these youngsters, particularly the more highly gifted ones, feel isolated from their peers and perhaps from their families as they find that others are not prepared to discuss such weighty concerns.

When their intensity is combined with multi-potentiality, these youngsters become particularly frustrated with the existential limitations of space and time. There simply aren’t enough hours in the day to develop all of the talents that many of these children have. Making choices among the possibilities is indeed arbitrary; there is no “ultimately right” choice. Even choosing a vocation can be difficult if one is trying to make a career decision between essentially equal passion, talents and potential in violin, neurology, theoretical mathematics and international relations.

Generalizations

It seems like picking “something that answers more than one question” is probably the best choice. There is a continuum here, that anything that you do will satisfy some of the criteria for perceived happiness, but nothing is right or wrong. I think that understanding and leveraging your strengths is a good rough compass of how you can make the highest impact. Your happiness mostly comes from your expectations after your basic needs are met. Maslow suggests that humans need many things to reach highest potential, so ignoring any of the needs is likely to result in suboptimal performance. You might have a noble mission, but if you can’t eat, you won’t be at peak performance.

It seems to me that the highest potential for doing something great comes when you are fully engaged in a pretty challenging activity that has actual meaning, and one especially that you connect with at a deeper level. Flow.

I suppose things depend quite a bit on your priorities or preferences. If you value stability or are risk-averse, a steady job is something that is probably important to you. If you value spontaneity or risk taking, perhaps being a freelancer or entrepreneur is a better fit. Some of the questions are somewhat or exclusively orthogonal. It’s pretty tough to make an impact like Gandhi and hold a steady job. Perhaps your greatest impact on others is your ability to have a wonderful family life, to come up with a new scientific theory, to run a business, or to travel the world and report your findings. Maybe you can do all of these. People certainly differ in abilities, interests, and energy levels.

At some point, you should make a decision. The original intent of the previous article (or at least as it can be applied now) was to say that not making a decision is still making a decision. It is a decision, whether conscious or not, to do nothing or take no action, or take action with something else. Sometimes this is a good decision. Sometimes you will regret it. But you won’t find out what you can do until you try.

There are certainly escape clauses. You can start doing something and realize that it’s already been done sufficiently, or you’re really not learning anything, or it’s really not as neat as you originally thought. I think there’s an analogy that’s apt. A man spends his whole life climbing a ladder and then realizes it’s leaning against the wrong building. If you keep your head down and work hard, you might be going in the wrong direction. I think this is where introspection is key.

Thanks for the comment. I greatly enjoyed reading it and responding. Still don’t have the answers, but thought this was interesting. Note that some of this is written to myself a couple of years ago. :)

Recently I’ve noticed an interesting phenomenon. Someone starts talking about a new idea or group or practice or strategy or improvement, and someone else says, “hey, I thought of that six months ago, but no one seemed to think that it was a good idea.”

In the past I read about the value of something being a function of the quality of the idea and the quality of execution. This makes a lot of sense to me. You can have the greatest idea in the whole world, but without effort and execution, there is no value. Even a medium quality idea done moderately well is useful.

I have about five hundred ideas right now. Some of them are pretty good, some are a little questionable, some old, some recent. Unfortunately, I am currently making $0.00 (that exchanges to 0.00 Euros) off of those ideas. That’s $0.00 worth of value that has been created by these written down ideas. They certainly give me a sense of excitement when I look at them, so I guess they’re worth something. I look back in fond admiration, and still think they’re pretty good. Hmm… maybe I’m attached. :)

But like the day when I sadly realized that I could never know everything there was to know, I have come to accept the idea that I will never have the time or energy to implement every idea that I have, even if (or perhaps, especially if) they are all five-star ideas. It wasn’t easy to accept.

Steve Yegge realized one day that he only had so many projects left in his life. He writes really long posts, so I’ll give a short quote from Rich Programmer Food, which is about why knowing about compilers is good for you:

Unfortunately, writing a compiler creates a living thing. I didn’t realize this going into it. I wasn’t asking for a baby. It was a complete surprise to me, after 20-odd years of industry experience, that even writing a simple interpreter would produce a lifetime of work.

Go figure.

I credit the phrase “a lifetime of work” to Bob Jervis, a friend of mine who happens to be the original author of Turbo C (with which I myself learned to program), and a damn good, even world-class compiler writer.

He gave a tech talk recently (Google does that a LOT) in which he pointed out that even just the set of features the audience had asked for was a lifetime of work.

This phrasing resonated deeply with me. It was similar to my realization about 18 months back that I only have a small finite number of 5-year projects left, and I have to start choosing them very carefully. After writing my own “production interpreter”, I realized that the work remaining was unbounded.

I mean it. Unbounded.

So from one perspective, I suppose I should just release what I’ve got and start marketing it, so other people will jump on board and start helping out. On the other hand, I started this particular side-project not to create a lifetime of work for myself (far from it), but to make sure I knew enough about compilers to be able to rant semi-intelligently about them, after a few glasses of wine, to a quarter million readers.

Sometimes ideas are ahead of their time by a couple of weeks or a couple of years. Sometimes they just aren’t expressed in the right way to the right people the first time. But you can’t give up if you believe in the idea. And it’s a lot easier to get traction for something when you start working on it.

What I’m trying to say here is that seeing a solution to a problem is not going to make a difference in the world. Applying your efforts and making your voice heard to make that solution a reality can. And even if you don’t succeed, if you’re smart you will learn how to do it better next time, and you may find something more valuable along the way.

Mike Kelly posted to the IWST news group about two upcoming group meetings that are taking place in Indianapolis. I listed them in order of perceived relevance. The first one is free, and is a day long, similar to the excellent IWST that I attended in September. The second one is not free, and lasts two three days. The first one seems particularly useful, although the second might be as well.

I’ve edited liberally, so here goes…

Workshop on Regulated Software Testing

May 15, 2009

The WREST is coming to Indianapolis again in 2009. The topic for the workshop is “Beyond Scripted Testing.” You can learn more about the workshop here.

…

Major Questions of Interest

How can we better test software in regulated environments while retaining processes and documentation that will pass regulatory audits?

How can we prove the value of implementing progressive test approaches within the context of the necessities of regulation (FDA, SOX, CMM, etc.)?

Workshop on Performance and Reliability

April 16-1716-18, 2009

Through much arm twisting and whining, the WOPR 12 organizers are hosting WOPR next year here in Indianapolis. The theme for the workshop is “Resource Monitoring During Performance Testing.”

You can find more details here.

…

The ultimate goal of performance testing is identifying and fixing performance bottlenecks before production deployment. While a large percentage of bottlenecks are ultimately traced to the application code, they may also occur in servers, system software, and network components. Critical to identifying their source and diagnosing their root cause is monitoring the “bellwether metrics”. Let us define “bellwether metrics” as the “key indicators of future developments or trends”, and thus the minimum set of system vitals that we should be measuring for each hardware and software component.

Thoughts

The process for applying to share an experience report was pretty easy. Just have some relevant experience and know enough about it to share. Come up with a presentation. Kind of like a brown bag really. If either of these two are similar in size to IWST, they are enjoyable because you get to know the people at the meeting. If you’re jazzed about this kind of stuff, you should totally do it, for both the knowledge and the experience.

Title: The Drunkard’s Walk: How Randomness Rules Our Lives Authors: Leonard Mlodinow Published: May 2008 Length: 272 pages

After taking two quarters of statistics and two of probability, I wasn’t sure that I would learn much by reading The Drunkard’s Walk. Fortunately, the history of the evolution of thought regarding chance and the ramifications of randomness on everyday life were explained to the point where I gained new insights into this area. It reinforced and clarified existing views that I had as well.

The most important point that was made is that there are a large class of things that humans typically see as being based on skill but are more likely based a great deal on luck. While CEOs and Hollywood film producers are paid top dollar for their skills, there seems to be little correlation with actual skill for their positions. Many events that involve human decision are unpredictable to the point that they can be considered random. I enjoyed the discussion of reversion to the mean presented throughout the book. Essentially, we tend to praise someone and see them as smart or skilled when they succeed, and then tend to disparage the same person when they do not appear to succeed. Mlodinow explains that our approval or disapproval often has little to do with someone’s next attempt because often the performance in the event is somewhat random. When I yell at someone, it is likely that they will do better than before. When I praise someone, it is likely that they will do poorer than before. Likewise, a mutual fund manager is likely to be lauded when she does well, and given the boot when she does poorly, even though picking stocks is a mostly random process.

The book discusses famous probability paradoxes such as the Birthday Paradox, Boy or Girl Paradox, and the famous Monty Hall Problem. These examples highlight how our intuitive grasp of probabilities does not necessarily accord with the actual probabilities. Understanding these better allows us to use reason instead of trying to us intuition, which is ultimately inferior in this realm.

In my opinion, this is similar to how people in economic experiments behave “irrationally”, or out of line with predicted economic theory. Examples of economic paradoxes can be found in books like Thaler’s The Winner’s Curse: Paradoxes and Anomalies of Economic Life. One of the tenets of traditional economics is that people are rational agents attempting to maximize their happiness. However, I feel that this assumption is flawed because that people do not always act rationally even when given perfect information.

I appreciated hearing about the history of thinking about probability because it was a perspective that I had not encountered in prior learning. The mathematics were nice as a refresher of probability and statistics.

One thing that the author talks about considerably is cognitive biases. Brains are essentially pattern-finding mechanisms, so they are bad at determining when something has been produced by a random process. People tend to spot clusters in dots that are sprinkled randomly because that is their instinct. Patterns may appear from stochastic processes, and conversely, we may not be able to detect patterns in deterministic processes. We also continually suffer from the myopia of confirmation bias.

The most profound implication for my life is that the best way to ensure that you succeed is to keep trying. Although I had a general idea that it is important to be persistent, this book reinforced the idea that trying multiple times is the only reliable way to boost your chance of success. Mlodinow states randomness is “why successful people in every field are almost universally members of a certain set-the set of people who don’t give up.”

A huge caveat of this view is that it assumes that the event that you are trying to have success at is random or that you do not learn from past experiences. It seems like in certain cases there is not an accurate model for agents to determine what will cause success or failure (stock market, predicting blockbusters from scripts.) I had some problems accepting that people are not successful based on their ability, but almost solely on luck. But if the results starting a company or creating a new product are somewhat random, why not try doing it many times? It should work out in the long run.

Overall, was an interesting read.

Here is an outline of the chapters.

The first breakout session I attended was the most interesting. It was titled “iPhone User Interface Design.”

The first point the presenter made was that the percentage of time that you spend on portions of the development cycle is quite a bit different for a successful iPhone app than most software applications. He showed a diagram that looked way cooler than this:

What this means is that you need to spend a lot more time in the design aspects of your app throughout the life cycle than you normally would. This set the tone for the rest of the presentation.

He defined “design” as mapping out requirements, doing the art and layout, and figuring out how core features and navigation are going to work. The cycle for developing a new product should typically go: familiarize, conceptualize, realize, finalize. Executing these well will take your application from average to excellent.

Familiarize

One solid suggestion was to read through Apple’s Human Interface Guide. Apple has spent a lot of time thinking about how people will interact with the iPhone and iPod Touch, so you don’t need to duplicate their work. What’s more, there are many conventions that you will be unaware of and unwittingly break. For example, Apple intends all buttons to have rounded corners, so if you have something that’s not a button, don’t make it rounded. Likewise, buttons should look like buttons because users have a model of what a button looks like and what it does.

The presenter reiterated considerations voiced in the general session, such as thinking about where the user will use the application and considering general properties of the iPhone and how it differs from the web and from a desktop computer.

One significant suggestion was to design for the thirty-second use case. You need to consider that the user wants to open your app and get what they need within thirty seconds. If your app has a bunch of meaningless screens or has poor performance, it will significantly hinder your ability to help them. If it takes twenty seconds to navigate where they need to go, you only have ten seconds to please them. If you can save any time by remembering or determining data (zip code for searching for restaurants, for instance), you should do that. It takes a lot of time and mental effort to type things in on the iPhone, and it would be very annoying if the user has to type something in multiple times.

The Pareto Principle must be invoked at least once per usability discussion, so here goes. You should design for the 80% use case. Make the most common functions be dead simple. With the limited screen space that you have, consider eliminating ancillary functionality. Make your apps hyper-specialized and super-focused. Apps that do everything do nothing. I liked this approach because it reminded me of something that the folks at 37signals would say (review forthcoming.)

Conceptualize

The key to conceptual design is to define a solution not a collection of features.

Consider the example the speaker presented: you are an interior decorator and you learn about the iPhone. You see something that makes you think of creating an interior decorating app. Your mind whirls at how this will make your life so much better. You grab a piece of paper and a pen, and scribble as fast as you can. “Wow, I can take pictures and store them in an album, and then upload it to my Mac. I can generate textures and hold them up to the wall. I can use the iPhone as a level to make sure that my wall hangings are straight. I can use this same app to make estimates of how much a room will take to redo.” The list grows to a page, then two pages.

This is exactly the wrong way to do an iPhone app.

You need to have a very lean feature set. If you start with an idea and brainstorming, or if you are modeling your app off of an existing app, you already have too many features. You need to prune.

A great way to prevent featuritis is to create an app definition statement. This statement summarizes the purpose of your app, and every key design decision that you make should be based off of it. With this much importance, it’s critical that all of the stakeholders buy into it. An example of an app definition statement is “Easy to use digital photo sharing for iPhone users.” Note that this definition statement clearly identifies who will be using the app and what they will be doing with it. Less is more with respect to features. Condensing your app is helpful for team morale and cohesiveness.

Realize

It’s important to understand your application type to make the correct design decisions. Apps live on a continuum of [serious..fun] and [entertainment..tool]. If you have a serious tool, you need the UI to be out of the way as much as possible. The user is just trying to get something done quickly, so there should be few frills. If you have a fun tool, you can get away with more graphics, but not at the expense of functionality. In other words, users will tolerate some distractions. If you have a fun entertainment app, it should be interaction driven and intensely graphical. This would mostly correspond to games. There also exists serious entertainment. This concept might seem silly at first, but could be something like a movie player. In this case, you would want the app to be more data-driven, and have a minimal UI.

These are the extremes, so you should consider to what degree your app is serious or fun and made for entertainment or utility. In conjunction with the app definition statement, this will help you decide what design elements should be used for your application.

As far as aesthetics go, you should remember to avoid having too much stuff on the screen at one time. Ask yourself: does this really need to be on the screen? Could it be hidden instead? Also: what’s important right now? Could this be shown later or on a different screen? Avoid layout cramming and make sure that your padding is consistent throughout the app. This is a professional touch that will separate you from the crowd. You should use built-in controls where appropriate because users are familiar and they are well tested, which saves you a lot of time. If you have options that aren’t commonly changed, put them in the global options file so you don’t have to keep showing them.

The biggest message to me of this section was to do paper prototyping or “iterate with paper.” Many fewer resources need to be expended to create a paper mock-up of the screens you are going to have, and getting the flow down is critical to the end user experience. You need to solve for all of the edge cases up front and see where your metaphors break down. Doing this on paper lets you experiment with several ideas and see which one fits your target user the best. One recommendation that made a lot of sense was to actually Xerox your iPhone or create a stencil to create a template that has exactly the right dimensions.

The presenter demonstrated how several apps evolved through time and it was clear that spending time with design was crucial to get their apps working optimally.

iPhone specific

This section is pretty specific, you can skip it if you aren’t interested in some nitty-gritty details. However, there’s one more section after this one.

For navigation, the standard is to move from left to right as you progress through the app. You should have a navigation bar with a title to give users an idea of what they are looking at. There should also be a back button. You should provide controls to filter data down.

A de facto standard is to have any kind of element addition be in the top right-hand corner of the screen. The same is true of edit controls.

Although you should have a title for context, you should avoid breadcrumbs and home buttons. Breadcrumbs are not scalable due to screen real estate, and both breadcrumbs and home buttons provide the possibility for a state change that is dangerous to the user’s mental model. If they accidentally tap one of the links in the breadcrumbs or hit the home button, they will become very confused and frustrated. This works for the web, but not on the iPhone, based on what Apple has seen in apps.

When you use lists and pickers, try to group similar items if possible. Associate an icon, as the eye typically sees icons first, then words. If you do have icons, try to make them minimalistic. If you have multiple screens with tables, try to switch the formatting up a bit to let the user feel like they are making progress. One more note on pickers: they are optimized for 12 items, which happens to be three swipes of a finger. :)

Finalize

You can (and should) enhance your application with photos and imagery. This aids in quick recognition of your app. Your icon is really key, as it is the first thing people will look at when they are evaluating whether your app is worthy or not. One thing that I probably never would have thought of is that users actually appreciate expensive-looking textures. If you can get some mahogany or marble or polished chrome textures, these will make your app look more valuable than other apps with standard backgrounds or textures. Don’t go all out and then skimp in the finalizing section. While your app will have great value, people often judge the book by its cover.

You can add excitement with animations, but be sure not to go overboard. You want them to give feedback so they are functional. A great example is how the iPhone home icons jitter when you are trying to move an application around. Functionally, this shows the user that they have entered a different mode than the standard mode. Emotionally, they see that some of the icons are excited because they might get to move to the front page, and some icons might be shaking because they are worried that the might get deleted! :) So it is fun and entertaining and also gives insight into the current state of the system.

I think that communicating application modes is a very important topic. My own example is when you start typing something in Microsoft Word but you keep overwriting characters that they have already typed. Because the ‘insert’ mode is not shown well, you might have no idea what the heck is going on, and can be extremely frustrated or even lose data.

Once you release, you can’t rest on your laurels. You should keep iterating and use customer feedback if you can get some. Better yet, if you can somehow track which features users use and how they use them, you can use this data to improve it empirically. That’s something I just thought of. But overall, you need to make sure that every release you have is high quality. Users don’t have patience with this kind of stuff. They will just uninstall your app without waiting for updates.

Let’s summarize: familiarize, conceptualize, realize, finalize. One more post to go-and that’s a lot of -izes!

You can see the first part of this series here.