Perfect is the enemy of good.
I will explain.
Imagine a line graph for any large software project you have worked on (Must be all new development, not a 2.0 or 3.0), where "Benefit" is the vertical axis and "Time" is the Horizontal Axis.
Think about the features and the order you did them in. Unless you are into Big Design Up Front, I'm guessing most of the projects look very similar - the benefit level steadily increased until it hit a certain point, then continued to increase but at a slower and slower rate.
In Math terms, the graph hit an "inflexction point" - a point at which the rate of increase began to go down. In physics terms, if benefit is speed, then there was a point where speed continued to increase, but acceleration started to decrease.
What does all this mean?
Well, imagine a typical software project - developing a complex Graphical User Interface.
At some point, someone is going to realize that the GUI is intimidating and complex, and getting worse as you add features. They will suggest a "Basic" and "Advanced" Interface View.
At which point someone says "Why not let the user customize the view?"
Except that they might want to switch between views quickly - so the programmers talk about a "Templating" system.
So then some designers have to go design a half-dozen templates - then the arguements become:
-> Which templates should ship with the system?
-> Once that's done, arguments erupt about tiny details of those templates, and what they should be called.
-> Which template should be the default?
-> Arguments about the usability of the templating system ...
All of a sudden, people are spending 20 hours a week in meetings, and nothing is getting done.
What's going on here?
Simply put, the project hit it's inflection point. The features grew to the point where the needs of the customer base diverged - so custom feature for person X was different than what person Y needed.
At this point, the decision maker faces a tough choice:
1) Split the project into multiple, less profitable, customization projects, or
2) Pick a customer base as a "favorite" and do it the way they want, or
3) Choose not to decide and ignore the issue, or
4) Cut controversial functionality.
If you realize you've hit the inflection point, it may be worth your while to consider option 4.
I'm currently working on a 2.0 release of a piece of complex software. The GUI for the software was massively complex. The first thing I did was to cut the number of fields down from 14 to one - and design an "advanced" search screen with six fields.
My first reviewer responded that she really like it, and was very happy with the "improvements."
Sometimes, the best improvement is to take things away.
Of course, the next question is "What additional things does this need to be useful?" - and we'll be pushed back by the userbase to make the software complex. The challenge is to walk the edge - for example, somebody's going to ask for templates, and a decision maker needs to be able to realize that the Return On that Investment makes the answer "No."
Too Much Time. Too Little Benefit.
In many projects the challenge is to get to that 80/20 rule - Where 80% of the functionality can be developed with 20% of the effort. Hit the inflection point, then stop.
Am I arguing that our software should be "Good Enough", not Perfect?
ABSOLUTELY! If the project has more than one person, you could a horrific amount of time in meetings deciding what is the 'right' way to do things.
That's why I love Perl. Part of the Perl Culture is simply: There's more than one way to do it.
Extreme Programming fits in well with perl: Do the simplest thing that could possibly work (but designed, or "Factored" well), and, if you have to come back later and change it, it should be easy to change, because it's designed to be malleable.
If you make your software good enough, it might not be perfect, but it will probably actually get finished since pefection doesn't exist this side of heaven, striving for perfect software might get you somewhere, but it's just about as likely to produce a perfect feature set that is never implemented.
(Note: It was Eric Sink's Article Career Calculus that got me started on this road.
