This is a great question. In my experience many programs that work well often have code that is not pretty at first reading. The important thing I think is to understand both the code AND the environment in which the code was written. I think considering one without the other is pointless. Was the management geek averse? Were the engineers formally trained or did they learn by doing? Was there a time crunch, a big customer waiting without baited breath for the new piece of software? Did the developers focus on it working well with minimal configuration regardless of the elegance of the framework? Was the group all about mental masturbation and framework creation rather than implementation, testing and actually finishing something? I think it may be time for a kind of Natural Selection/Turing Test to asses the quality of a particular development approach: Imagine if you had a large sample of users. Now if all of these uses feel that the software performs exceptionally at its task that it is just flat-out awesome can we conclude that those who wrote it did an excellent job? If those that wrote the software did an excellent job, by this standard, then regardless of what approach they took, they produced great software, even if it did not follow one particular school of software development. The bottom line is that the environment and the approach play a role in selecting what software is "good". Another point to consider is that Software Engineering/Development is a relative child (Internet is 16 years old or thereabouts) compared with other more mature disciplines. Consider Electrical Engineering or Industrial Engineering, compare an Anti-Lock breaking system to a virus scanner or a modern UI with a modern speaker enclosure. Where is the "schematic diagram" for a program (and please don't say UML)? I follow the sort of evolutionary approach I guess. Design a good deal (use patterns and language facilities where appropriate), but focus on getting the thing working and working well; test it a lot, move it around as soon as you can (e.g. deploy it to a new environment), get it in front of judges(users) then enhance and test lots more, get it out there fast, but not totally kludged together. After a few iterations of this a real framework emerges (the kind software preachers say is there from the beginning) which should as soon as it is visible be implemented.