Why do you think we have so much time logged under "stabilization"?

An aspect of building software that I both love and hate is the transition from paper (spec/design) to actual working software. On the one hand there is something very satisfying about seeing actual working code.  It's thrilling to us geeks. On the other hand, one of the unfortunate side effects of the way contemporary (read: agile...-ish)  projects get managed where the software is broken down into small chunks for implementation is that it can be difficult for the developers to "see the forest through the trees".  In other words you get a lot of technically "correct" (read: works as spec'd) code that doesn't actually "work".  
 
In the enterprise, responsibility for avoiding this generally falls on the "integration testing" team, but in my experience many of the problems aren't necessarily caused by disjointed features, but a lack of understanding about how the potential customers on the site actually interact with it.

It turns out design matters.

Title: Why do you think we have so much time logged under "stabilization"?
Snarky: I didn't realize there was such a fine line between fixing bugs and gold-plating.