- 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
Poor Skill Set Fit
Some parts of mobile development are more difficult than others, and some are relatively easy. Unfortunately, it’s not immediately obvious which parts are which, and it varies from platform to platform. It’s actually common for a developer who is familiar with one programming language or library to believe that familiarity is more relevant when moving to a new programming language or platform than it actually is.
Example: Threading on the iPhone
Most development platforms and operating systems these days have something called threads, which you can think of as containers inside an app into which commands are placed so that they can be executed. By having multiple threads, an app can do more than one thing at the same time (or nearly the same time). For example, one thread can be redrawing the app’s screen as it scrolls, while another thread is downloading a video that will be displayed at a later time.
If a programmer knows how threads work, and that programmer learns that iOS (the operating system that runs on the iPhone and iPad) has threads, that programmer can easily assume that he or she knows how to make the iPhone do multiple things simultaneously. But he or she would be wrong. Although the iPhone does have threads, it also has queues, and Apple recommends that programmers should almost always use queues, and Apple’s libraries then manage the threads automatically. Programmers who don’t realize this often use the wrong mechanism and create their own threads, which can cause the app to malfunction under load.
The bad news is that when there isn’t a whole lot going on (for example, when you’re using small amounts of test data), spawning your own threads works fine. If the programmer assumes that it will work the same way with a lot of data, then he or she will likely fail to test at higher loads. Such an app may develop unexpected, undesired, and likely unacceptable behavior right at the end of the development cycle.
Your App Isn’t Just Any App
The takeaway is that different apps need different skills, and just because developers did a good job with someone else’s app doesn’t necessarily mean they can do a good job with yours, unless the apps are really similar. Unfortunately, you can’t always rely on developers to volunteer what skills your app needs that they lack (especially since it’s in their best interest for you to hire them, and for you to do that, they want you to think they know what they are doing).
But don’t worry. In Chapter 4, “Determining Your App’s Components,” you’ll learn how to figure out what skills your app needs, and in Chapters 7, “Finding a Developer,” and 8, “Interviewing and Selecting a Developer,” you’ll learn how to select the developer who is the best fit you can find.