Monthly Archives: January 2010

Thought I’d share an excerpt from Chapter 3 of our book “Effective UI: The Art of Building Great User Experience in Software“. By far, this the most definitive explanation of why enterprises need to reconsider how they’ve approached software development in the past. RFPs, Fixed Bidding, Waterfall, all have dangerous implications to the success of any software project. Many companies use the wrong analogies when planning projects; they plan using construction metaphors. This chapter does a great job explaining that in reality, planning a software development project should be more like planning a war.


Uncertainty and the Unknown

Uncertainty and the unknown are enormous, unavoidable, and fundamental components of every software development project. Being at peace with this reality means you can approach the project in a way that adjusts and flows to account for the unknown. If you fight uncertainty and the unknown—or, even worse, if you suppose they don’t exist—it’s a path to defeat.

The mistaken belief that uncertainty can be entirely stomped out through upfront planning and everything can be known in advance is the root of many of the worst problems and errors in the management of software proj- ects. This arises from the misapprehension that software development is com- parable to and can be managed like other types of large-scale engineering proj- ects—building a bridge across a valley, for example. Bridge building and soft- ware development both have components of science and engineering, and of art and craftsmanship. But the role of uncertainty and the unknown, and the way science, art, engineering, and craftsmanship work together throughout the course of the project are very different. Those differences demand a fun- damentally different approach to management of the project.

The notion may seem discouraging, but it’s much more accurate to compare software development to war than it is to compare it to bridge building. While the battle of software development is fought more with electrons and Mountain Dew than bullets and napalm, the battlefield is a complex, dynamic, unpredict- able system of activity residing in shifting political and operational contexts.

The Humility of Unknowing

I am the wisest man alive, for I know one thing, and that is that I know nothing.


To demonstrate how uncertainty and the unknown are inevitable compo- nents of a software development project, we’ll examine why the bridge- building analogy fails and the war analogy succeeds. But even with the aid of analogies, it’s extremely difficult to explain why uncertainty and the unknown are unavoidable to someone who’s never been in the trenches of a software development project. Much of the understanding comes from see- ing how design, creativity, and inspiration factor into every aspect of build- ing an application. It also comes from having seen how false certainty, and the demand for it, can cause failure and lead to poorly designed products.

It’s difficult to explain or prove this fact except to state it this way for now: you understand your project far less than you think you do.

And so do your stakeholders, by the way. For your project to be successful, you need to cultivate in yourself and in your stakeholders a certain humility and a recognition that, for as much as you know, you know very little, and that the essence of the project is to investigate and solve a complex problem and not simply to implement a known solution. Embracing this humility of unknowing isn’t a resignation to defeat or admission of weakness, but rather is a state of wisdom required to allow you to succeed.

The Weakness of Foresight and Planning

The great uncertainty of all data in war is a peculiar difficulty, because all action must, to a certain extent, be planned in a mere twilight, which in addition not infrequently—like the effect of a fog or moonshine—gives to things exaggerated dimensions and unnatural appearance.

—Carl von Clausewitz, On War

Everything required to design a bridge to a valley is knowable in advance and can be planned to an extremely high level of accuracy before construction begins. All of the important goals, variables, and constraints can be accurately obtained before design begins.

Once those key considerations have been discovered, the design of the proj- ect begins and can be entirely completed before construction starts. With accurate and complete designs in hand, construction is then all about ensur- ing the pieces all come together as designed. Construction is not concerned with any remaining questions about the design and isn’t burdened by the risk that the design will change during the course of construction.

By contrast, a general preparing for battle can estimate the strength and disposition of his forces, the resources and capabilities available to him, the attitudes and aptitudes of his commanders in the field, the lay of the battle- field, the strategic goals of the battle, the state of the enemy’s forces, and the parameters for success. He also has history and personal experience to help him intuit how events will unfold. Based on this knowledge, he can formu- late a plan for the battle.

But this plan, no matter how carefully devised, is inherently incomplete and imprecise. It is wholly premised on estimates of the conditions before the battle and entirely ignorant of the unforeseen conditions that arise during the battle. These unforeseen conditions are based as much on the vagaries of weather, emotion, chance, and uncertainty as they are on even the best-laid plan. This reality is the basis for the famous quote:

No battle plan survives first contact with the enemy.

—Helmuth von Moltke

The same is true of software development. No matter how well you think you understand the domain and no matter how earnestly you’ve thought through the requirements, there is still great uncertainty in the original facts and premises and a vast depth of the unknown still awaiting you. As with battle, the outcome will be determined at least as much by what comes dur- ing the course of the project as by what comes before it.

Not all unknowns are bad, by the way; it’s in solving the unforeseen problems that great design and inspiration can take place. Some unknowns may be rev- elations about your customers and users that fundamentally change how your business interacts with them, or they may be undiscovered opportunities for progress, innovation, efficiency, and improvements to your company’s bottom line.


If you are interested in reading the whole chapter, you can download it here.

More excerpts are available here

Better yet, don’t be so darn cheap and just go buy the book here

I thought I’d have a little fun predicting what Apple will be announcing on Wednesday.

Apple will preview OS 10.7, it will feature:

  • the once code-named “Marble Interface”
  • be more oriented to gesture based interactivity
  • snow-leopard was almost a complete rewrite, no big new features. 10.7 will be focused on “sexy” new features that were left out of snow-leopard

Apple will preview iPhone OS 4.0 It will include:

  • some modified or light version of multi-threading
  • a new home page (look for some unique coolness here)
  • something new for peer-to-peer iPhone communication
  • better 3rd party device support
  • No Flash
  • Google will not be the default search engine
  • a newer way to more easily write web-based applications (HTML 5 on steroids)

Apple will then announce a tablet, they will call it iPad. The iPad will feature:

  • 10.1″ LCD Touch Screen
  • 1/2″ think
  • 4 buttons
  • 2 doc connectors
  • Forward facing, 5megapixel camera
  • WiFi and 3G connectivity,  Verizon and ATT to offer subsidized pricing
  • No Flash support
  • 6 hour battery life for reading, 4 hour battery life for video
  • super fast ARM processor running something closer to the iPhone OS versus Snow Leopard
  • all AppStore applications should work on the device with little to no modification
  • 3D interface, something we’ve never seen before
  • Features focused on entertainment/games, publishing/books, video, communication, and social networking. We may even see some demo apps running in these categories
  • 2 flavors: $700 for 64gig, $900 for 128gig (prices are before carrier discounts)
  • iWork integration
  • Content Partners announced: Harper Collins, Time, New York Times, Random House, and Conde Nast, and every major content provider already on iTunes

I also believe Apple will hint at things to come. For example, new ways that advertisers might be able to subsidize the costs of these devices. Additionally, they will show ways the iphone, 10.7, and the iPad all work together in ways we never thought possible.

Always fun to speculate, lets see if I’m right on any of this :)

Patents were invented in order to encourage innovation. They are supposed to protect inventors that spend money in research or discoveries made by innovative thinkers. Without them, many would argue, the United States would not have ever seen the industrial or digital revolutions.

However, there are enterprises that using the patent system in a way that is killing innovation. We all hear about enterprises using patents as defensive mechanisms for their own patent infringement issues… Company A sues Company B for infringement – Company B sues Company A back for other patents they own, the lawyers get a big fat payday while consumers are ultimately left holding the bill.

But what is worse are the companies that patent something ridiculous and then simply use the patent as revenue stream to sue other companies for infringement.

A few years back, Macromedia launched a feature in the Flash player that allowed you to print something that was off-screen. A few months later, a company called Post Future patented the ability to print coupons using the web even thought the end user could not see it. In other words, they patented a feature built into Flash (they vigorously and successfully defended the patent many times over).

But today, as a part of our SODA membership, I just became aware of a patent that has my blood boiling.

Patent 6,351,265

PixFusion holds the patent for swapping heads in a photograph digitally. The patent is 23 pages long.

Lets walk through the abstract really quick:

A method of providing normalized images, comprising the steps of:

(a) receiving an electronic representation of an image including a head;

(b) extracting the head from the image;

(c) determining a size of the head;

(d) rescaling the head to a plurality of desired sizes; and

(e) outputting the plurality of rescaled heads as printed images on a medium.

So, I decided to see how long it would take me to actually do this.

First – receiving an electronic image including a head

I simply took a picture of Shannon and Buffy using my iPhone, and then pulled (received) that image using iPhoto…

Second- extracting the head from the image:

There are lots of options for this in photoshop. I chose to duplicate the background onto layers, then erased the background away (notice my awesome photoshop skills)

Third & Fourth – determining the size of the head and rescaling

This was quite difficult. Because Buffy’s head is slightly bigger than Shannon’s, I had to use their noses and mouths to resize their heads to fit their bodies. The patent calls this process “using reference vectors”:

The method according to claim 1, wherein said head has a reference vector and said body has a reference vector, further comprising the step of combining said head and said body to obtain a predetermined multidimensional relationship of the respective reference vectors of said head and said body.

Finally: Outputting the image

This one was the most difficult. I had to… wait for it … print the image. Here’s proof that I did it:

All in all, it took me 5 minutes to complete the task. Ironically, the patent claims that this process is quite complicated, requiring unique skills and equipment (it was approved in 2002 – so scanners, digital cameras and photoshop all existed at the time)

I realize that this may seem funny to those of you reading this, but the fine folks at PixFusion are actually aggressively pursuing their rights under this patent. For agencies, it is a nuisance at best, a huge resource hog at worst. Patent squatters are taking advantage of the lack of resources and education in the patent office. There is NO value in the world for holding this patent.

I hope to hear back from them, and I promise to include any communication with them in my Blog

some of my favorite excerpts from the patent:

In the following description, the term “head” is intended to include not only the head of a human being with its hair (however long) face, ears, etc., but also any and all appurtenant accessories such as a hat, glasses, hair adornments, jewelry (earrings, etc.) and the like. The term “body” as it is used herein, is intended to include the body of a human being, animal, fish, etc., (either real or fictional) including not only the torso, arms, legs, tail, fins, etc., but also any and ail appurtenant clothing, shoes, jewelry, and the like. The “body” may also be another environment in which an image of a head is appropriate, such as a window, television screen or portal. The image of the head and/or body may be obtained from a “real” head or body, respectively, either photographically or by electronic image scanning, or from an artistic or computer generated rendering thereof

In order to facilitate alignment of the head and body, and relax the necessary tolerances for an aesthetically pleasing result, a collar may be provided on the body immediately adjacent to a location of said superimposed head. Alternately, a neck portion may be provided on the head, with a reference point on the neck. A soft pink border may be provided around the head.

According to a still further object of the invention, the images may be associated with audio information, such as spoken words. These words may include, for example, the name of the person whose head is included in the image.

In another embodiment, the body part images may be interchangeable for placement with a range of different background images, in the manner of the known “Mad Libs”, allowing humorous combinations of foreground and background images. In this case, the various anatomical body part images may be of the same size yet differ in other additions or characteristics, as discussed above.

%d bloggers like this: