When the iPhone was unveiled in 2007, it was a revolutionary device on many fronts, but chiefly because it was simple to use.

But it’s not enough just to have the idea of producing a simple phone.  Everyone knew that phones were too complicated.  It was a different matter to actually build one.  This is what was so hard.  Simple to use and simple to build are two very different things.

When RIM ( the creator of the Blackberry and the market leader) saw Steve Jobs’ simple demo, their reaction was not to copy the “great idea” of building a simpler device.  Their reaction was to laugh it off as impossible.  It couldn’t be done.  It was too difficult to build.

Apple was effectively accused of lying as it was supposedly impossible that a device could have such a large touchscreen but still get a usable lifespan away from a power outlet.  [RIM believed] the iPhone “couldn’t do what [Apple was] demonstrating…”

RIM is not a stupid company.  Their assessment of the iPhone as virtually impossible to build was completely accurate.  Their only miscalculation was just how many tens of billions Apple was willing to spend to bring this “simple device” to market.  Over 200 patents.  Billions of dollars in acquisitions.  Nearly 5 billion in R&D.  Thousands of full-time hardware and software engineers.  Investing billions in chip design at a time when every other computer manufacturer has outsourced all design overseas.  All to build a simple phone.

Like the iPhone itself, looking at an app project from a consumer’s point of view is like looking at the tip of the iceberg.  “Simple” applications are always the most difficult kind to build, because they require all of the complexity to be carefully hidden from the user.  Simple, well-designed applications have so much hidden below the surface.

Complex applications, in contrast, can sometimes be the easiest applications to build.  The easiest app to build is the one that does nothing–that requires the user to do all the work.  The less work the user has to do, the more work the programmer has to do, and the more complicated the project will be to build.

This is why it is so important to have a software developer on your team from the start.  A good developer will instinctively know what is “below the surface” for any proposed feature and will be able to guide the design to stay within budget and focus on those features which can be implemented within time and schedule constraints.

If you don’t have a software developer on your team from the start, you are doomed to making terrible decisions about designing any app, big or small.  You can only see what is “above the surface”, and you have know way of knowing if the “simple” menu you asked for is a few hours of effort or it really has a few months of costs submerged below the surface.

Misunderstanding this “iceberg principle” is perhaps the most common source of software project failure.  In the industry, it’s called the 90-90 rule:  the first 90% of the code takes the first 90% of the time, but the last 10% of the code takes the other 90% of the time.  In other words, the time and cost to implement a feature often has no determinable relationship to the user-visible part of the feature.

From our vantage point in the iOS development market, the unfortunate design procedure is usually something like this:  the client comes with a laundry-list of features without any technical guidance in creating the list, a list full of iceberg-features.  The client is tight-lipped about the budget because they want to shop the project to many different firms.  None of the contractors are sure whether they should cut a few of the pricey features to fit inside a budget, so everybody guesses what number the client wants to hear.  The company that wins is the one that says the lowest number–the company that failed to see most of the submerged complexity–usually the least competent firm.  Then the project runs over-budget and fails.

In reality, software development is a conversation.  Here’s what can be done for $20k, here’s what can be done for $50k, here’s what can be done for $100k.  If you  haven’t had that kind of conversation directly with a senior developer (not a sales rep), your project is doomed before you’ve written the first line of code.