- App Projects Are Not Small and Easy
- Apps Are Not Easy to Program
- Poor Skill Set Fit
- If You Get a Good Developer, You Still Have to Worry
- The Idea Is Not More Important Than the Execution
- Unwillingness to Delegate: Micromanaging
- Bikeshedding
- Poorly Defined Requirements
- Out-of-Date Requirements Documentation
- Constantly Changing Requirements
- Leaving the Worst for Last
- Cost Overruns
- That Last 10%
- The Whack-a-Mole Problem
- Poor Communication
- Abdication of the Management Process
- Wrapping Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Idea Is Not More Important Than the Execution
A common fallacy is that once you get an idea for a great app, you’re most of the way there. In fact, that’s not the case at all. As with most other inventions, a truly exceptional idea is still only the first step in the process of making an app.
In the process of making an app out of that idea, literally thousands of additional decisions have to be made. Some of those decisions involve colors, graphics, data storage, workflow, architecture, layout, transitions, animations, and monetization, and each of these requires even more related decisions. Some of the decisions you need to make have a wide-ranging impact on the success of the app, and some have little or none. It’s not always possible to tell how much of an app’s success or failure is attributable to any particular decision. In general, I’ve found that app creators often underestimate the impact of each of the little decisions.
Each decision must be executed upon and turned into code, and that code becomes part of the final app. There are lots of opportunities for poor execution in this phase that can render an otherwise fantastic idea unworkable.
There Is No Idea So Good That It Can’t Be Poorly Executed
There’s a tendency I’ve seen among app creators to become so enamored of their idea that they don’t want to worry about anything else. They often say (or think) they are looking for a developer to “implement their idea,” by which they mean to make all the decisions and execute those decisions, often in return for half (or less) of the app’s eventual revenue. I’ve never seen or heard of this strategy working out (which doesn’t mean it can’t, but it’s definitely a low-percentage bet).
The root cause of this situation is usually that the app creator doesn’t participate in the decision-making process except at a very high level. In such a case, the developers end up implementing their own vision instead of the app creator’s, slavishly copying some other app, or just guessing what the app creator wants.
In the virtually certain event that the app creator is unsatisfied with the result, an adversarial relationship usually forms between the app creator and the developer. The app creators point out things that they consider to be obvious deficiencies (but generally can’t articulate or communicate alternatives in sufficient detail to be implemented). The developer, frustrated, builds something else that is still unlikely to appease the app creators. And the cycle often repeats.
Programmers often refer to this as “rock fetching,” and it can be hugely frustrating. Imagine the following scenario:
- Your boss: “Bring me a rock.”
- You, after bringing back a rock: “Here is a rock for you.”
- Your boss: “I don’t like that one. Bring me a different rock.”
- You, after getting a different one: “How about this one?”
- Your boss: “No, I don’t want that one either.”
- You: “What’s wrong with it?”
- Your boss: “I just don’t like it.”
- You: “What kind of rock are you looking for?”
- Your boss: “A better one than that one.”
- You: “Better how?”
- Your boss: “You know, better. Rockier. More rock-like.”
- You, confused and hesitating: “Uhhhhh.”
- Your boss: “What are you waiting for? Bring me a rock.”
Most people find rock fetching irritating. It certainly doesn’t facilitate a person’s best work. Given enough of this, most people will eventually quit. But when app creators refuse to involve themselves with detailed questions about how an app should look or work and either don’t know or can’t communicate what they really want, they create a rock-fetching scenario.
A word of warning: Some developers love this kind of app creator and are happy to continue billing by the hour to write code that will be rejected until the app creator runs out of money. Personally, I find this distasteful, but some legitimate developers make the argument that they aren’t responsible for their customers’ whims or lack of requirements. And they have a point. Caveat emptor.