- 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
Bikeshedding
Some projects feature endless repetitive design meetings with arguments over font sizes, RGB color values, and pixel-level control placement. The developers are paralyzed and spend a lot of (billable) time waiting for decisions to be made by the client, and progress is correspondingly slowed.
I’m not implying that control placement or color choice aren’t important—they are—but they should take up a relatively small portion of the overall project budget and schedule (at least for the vast majority of apps).
C. Northcote Parkinson coined the term bikeshedding in 1957 for groups spending far more time arguing about things that don’t matter than things that do. The canonical example is a group of townspeople tasked with commenting on plans for a nuclear reactor spending their time arguing about the color of the bike shed at the reactor. Obviously, the color of the bike shed makes no difference to the efficiency or safety of the reactor, but it’s something that everyone in the group can feel qualified to have an opinion about. Everyone wants his or her opinion to be heard about something and to leave a mark on the project, so any trivial item can become a source of arguments. For the important things (like cooling redundancy and radiation shielding), the nuclear experts’ opinions are usually left unquestioned because no townspeople in the group feel qualified to argue those points and don’t want to be responsible if they turn out to have been wrong.
Most app creators don’t have much (if any) experience with app programming, and so they don’t feel qualified to weigh in on issues of coding style and data models. They do, however, often feel that they are qualified to give opinions about colors and fonts and graphic design. So in trying to feel in control, they cause large amounts of time to be spent on noncritical items.