- 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
That Last 10%
Many people have come to me with projects that they believe are “90% complete.” They never have been. It’s hard to know exactly how far along a project actually is, but when someone tells you they’re 80% or 90% of the way done with a project, they’re almost always wrong. Why does this happen so often?
Well, first off, most people don’t actually bother to go through the effort of really measuring project status but want to act as if they know what they’re doing. So they tend to make up numbers, and 80% and 90% are good round, made-up numbers. Really, it’s just a common and convenient lie told by developers and project managers the world over. When people tell you they’re 80% or 90% done, ask them how they arrived at that percentage.
Despite the frequent fabrications, there is an underlying truth here: Most mobile app developers leave testing until the end of the project. Testing is how you find out how well a project is really going. If a developer has written code for half the features on the project, the project may be as much as half done. But if that set of features turns out to have tons of bugs, then there are tons of bug fixes that must be written before the project is half done. And before testing, there’s no way to know which.
What happens is that developers write all the code to implement all the features before turning over the code to QA for testing, and they assume that testing is just a formality and won’t turn up very much. They assume, for example, that the testing at the end will be 10% or so of the project time. When testing turns up a whole bunch of stuff, they stick to their guns and think (or at least say) that they’re still 90% done. This is where we get the joke that “the first 90% of the project takes 90% of the time, and the last 10% of the project takes the other 90% of the time.”
Avoiding this situation requires testing early, testing often, and testing the right things.
First, understand that early testing doesn’t reduce risk; it just reduces uncertainty, so it’s still important not to leave the riskiest parts of the project until the end. (See the “Leaving the Worst for Last” section earlier in this chapter.) Sequencing of features is still critical, even with lots of testing.
Second, each feature or component needs to be tested to make sure it’s functioning correctly. Note that it needs to be tested to make sure it behaves well when expected things happen and that it doesn’t behave badly when obvious but unexpected things happen. Most developers do at least an adequate job of this.
Finally, testing needs to verify that when each new feature is added, all the previous features still work. This is called regression testing, and lots of developers don’t do a good job of it.
For more about testing, see Chapter 12, “Communicating Using Bugs,” and Chapter 13, “Testing.”