Factors in successful software, in most typical business cases, ranked in importance would be:
1. Usability – It does what it needs to do.
2. Cost – It’s reasonably priced and/or delivered on-time & on-budget.
3. Performance – It does it in a timely manner.
4. Intuitive – It does things in a manner that makes sense without instruction, and work-arounds are easy to spot.
5. Stability – It doesn’t crash or do something weird.

Stability or bugginess isn’t black & white. That’s assuming there are minor issues in the application and no more than a “rare” crash in areas that are not critical operations. Obviously if it crashes a lot or bugs interfere with it doing what it’s supposed to do, then Usability is out of the door.

Writing “clean code” shouldn’t be about building it up from day 1 as the “perfect” elegant solution. It’s about ensuring that *when* you need to make compromises, the objective of all developers is to recognize the risk of those compromises and re-factor them out at the earliest possible time. Agile development is about constant re-factoring to deal with changing requirements and staying flexible with changing priorities. It ain’t going to be perfect all of the time, but it sure as heck should be getting better most of the time.

It’s a similar argument I’ve had with developers that want to write the “perfect” framework for applications, ultimately flexible and can be used for the next 10 years. The funny thing is that most of those same developers give rather blank looks when I ask them if they’re remotely interested in working with 5 year old code. Perfection is the target, but if I can deliver saleable, usable product in 2 years making compromises, or 4 years making no compromises, I will chose 2 years when it’s my ass on the line. I expect nothing different from the companies I work for, though I do still push back.