David Yardy's post about project post-mortems reminded me of something I learned awhile back.  Here's the premise of David's post:

Before and after developing software it is often to have the similar thoughts regarding the project.

Before - "This project should be easy and quick."

After - "Why was the project so complex and take so long."

He then listed 5 excuses that are often used during a project post-mortem:

- project resources were limited by time
- resources were not trained or skilled enough
- the customer was more involved than desired (refining documented requirements)
- the customer requested too many changes
- new technology was a source of difficulty

I don't remember where I heard it, as it's been a year or more (maybe Code Camp 2006), but I heard some good advice that helps address this issue.  Don't build 100% solutions; build 80% solutions.  If you always focus on a solution that addresses 80% of the problem, then you'll find yourself better off.  Instead of spending 80% of your time addressing the 20% edge cases, you can move on to the next project and address another 80% problem.

The edge cases are often what cause problems with:

  1. Resource limitations of time -- the edge cases take longer to address
  2. Training/Skill -- as the edge cases are harder to address
  3. Customer involvement/requirement refinements -- the edge cases can cause you to chase your tail with requirements
  4. Customer requested too many changes -- many times the changes are to address edge cases
  5. New Technology -- used to address edge cases more easily, causing all the normal cases to suffer