Coding Horror

programming and human factors

Escaping From Gilligan's Island

I find it helpful to revisit Steve McConnell's list of classic development process mistakes, and the accompanying case study, at least once every year. Stop me if you've heard this one before:

"Look, Mike," Tomas said. "I can hand off my code today and call it 'feature complete', but I've probably got three weeks of cleanup work to do once I hand it off." Mike asked what Tomas meant by "cleanup." "I haven't gotten the company logo to show up on every page, and I haven't gotten the agent's name and phone number to print on the bottom of every page. It's little stuff like that. All of the important stuff works fine. I'm 99-percent done."

As that old software proverb goes, the first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent.

The Classic Mistakes case study is unnerving to read; it's like those staged re-enactments you see on America's Most Wanted. It's an exaggerated but strangely accurate summary of every pathological software project I've ever participated in, which is to say almost all of them.

This is the phenomenon McConnell likens to Gilligan's Island. Every week there's some new, crazy scheme to escape the island, but at the end of the episode, the castaways always end up stuck on the island for yet another week.

The cast of Gilligan's Island

If you don't immediately see the parallels with software development, allow me to reacquaint you with the long, dismal history of software project failure. Classic mistakes are classic because they're so seductive. You have to actively recognize when you're falling into one of these traps. As Steve once said in an interview:

Actually succeeding in a software project depends a whole lot less on not doing a few things wrong but on doing almost everything right.

Which is why you should have every single one of the 36 classic mistakes outlined in McConnell's Rapid Development committed to memory by now:

People Mistakes Process Mistakes Product Mistakes Technology Mistakes
  1. Undermined motivation
  2. Weak personnel
  3. Uncontrolled problem employees
  4. Heroics
  5. Adding people to a late project
  6. Noisy, crowded offices
  7. Friction between developers and customers
  8. Unrealistic expectations
  9. Lack of effective project sponsorship
  10. Lack of stakeholder buy-in
  11. Lack of user input
  12. Politics placed over substance
  13. Wishful thinking
  1. Overly optimistic schedules
  2. Insufficient risk management
  3. Contractor failure
  4. Insufficient planning
  5. Abandonment of planning under pressure
  6. Wasted time during the fuzzy front end
  7. Shortchanged upstream activities
  8. Inadequate design
  9. Shortchanged quality assurance
  10. Insufficient management controls
  11. Premature or too frequent convergence
  12. Omitting necessary tasks from estimates
  13. Planning to catch up later
  14. Code-like-hell programming
  1. Requirements gold-plating
  2. Feature creep
  3. Developer gold-plating
  4. Push me, pull me negotiation
  5. Research-oriented development
  1. Silver-bullet syndrome
  2. Overestimated savings from new tools or methods
  3. Switching tools in the middle of a project
  4. Lack of automated source control

I've increasingly come to believe the only difference between experienced and inexperienced software developers is that the experienced ones realize when they're making mistakes. The same rule applies to software projects and project managers. If you're not actively scanning through the list of Classic Software Development Mistakes as you run your software project, you have no idea how likely it is you're making one of these mistakes right now.

Making mistakes is inevitable, but repeating the same ones over and over doesn't have to be. You should endeavor to make all-new, spectacular, never-seen-before mistakes. To that end, Steve McConnell highlighted a few new classic mistakes in his blog that he's about to add to the canon, 10 years later:

  • Confusing estimates with targets
  • Excessive multi-tasking
  • Assuming global development has a negligible impact on total effort
  • Unclear project vision
  • Trusting the map more than the terrain
  • Outsourcing to reduce cost
  • Letting a team go dark (replaces the previous "lack of management controls")

Steve is also looking for our feedback. He published a Classic Mistakes Survey and invited everyone to participate. If you have any kind of software project experience under your belt, please do.

It's true, the odds are against you. But it's a good idea to periodically remind yourself that maybe, just maybe-- if you can avoid making the same classic mistakes as so many other software projects before you-- you might actually manage to escape from the island one of these days.

Written by Jeff Atwood

Indoor enthusiast. Co-founder of Stack Exchange and Discourse. Disclaimer: I have no idea what I'm talking about. Find me here: http://twitter.com/codinghorror