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:
- Resource limitations of time -- the edge cases take longer to address
- Training/Skill -- as the edge cases are harder to address
- Customer involvement/requirement refinements -- the edge cases can cause you to chase your tail with requirements
- Customer requested too many changes -- many times the changes are to address edge cases
- New Technology -- used to address edge cases more easily, causing all the normal cases to suffer