What you consider measurable metrics, Spectra, are not necessarily relevant to the specifications so they do not reflect design
This is true, but they are usually side effects of a good design. Speaking from experience a poorly designed application will have a hard time passing any tests, nevermind trivial automated tests. But your right, they do not dictate good design, but then neither to design patterns, they only suggest a good design and that is left entirely up to the implementor.
applications usually need to perform only so fast so that the perceived user response time is fast enough. Any faster than that is not beneficial to anyone, and is a waste of development resources (as they say, premature optimization is the root of all evil
I disagree. Again I'm not refering to premature optimization I'm talking about a design that is left so clean it is by very nature more efficient.
Consider what would happen if you ran a poorly designed application through xdebug code coverage and a more efficient design.
The better design should incur less overhead from extraneous parsing due to the fact it's modules are more atomic/simple in nature and thus only the required functionality is ever included. I know you would never get this perfect everytime but I know my own application has an overhead of about 5-7%.
There are on average 350 lines executed per request and only about 50 lines of extraneous non-essential code that is never invoked or used. I am not optimizing prematurely at all at the algorithmic level but just opted for a simple design.
Most browsers implement the specs differently, and we have to work very hard to make it appear our sites appear the same on all browsers and validate at the same time
Precisely but standards are what separate the men from the boys. Yes it's more work to validate against W3C and have pages work properly in every browser but it just proves the dedication and quality of workmanship of the developer team in charge, IMHO.
Some of those validation rules are ludicrous - if an image has an "alt" property it is valid, even if that attribute is an empty?
I didn't write the specification I just try my best to conform to it. If not for my own ego than to use it as fire power against my competition as to why I am the better pick. Anyone can claim to be an OOP expert and it's difficult to disprove because whether composition should be used over inheritence is debatable and both are valid given certain cirumstances. However, one cannot claim to be W3C valid if the tangible tests show otherwise, can they?
so I could just add alt="" to every image and I'm validated now? this is especially true for web applications which push the browser to the limits and in my opinion should not be concerned at all with validation
Dude...I can't believe you said that. My application pushes the boundires in terms of AJAX and javascript too and guess what? Not only does it validate on every page BUT the application *functions* exactly the same when javascript is turned *off*. Things like drag and drop and WYSIWYG don't work but the functionality is still there.
I do this because (despite tackling the problem of XSS at the core of the framework) I figured I could just let a user disable JavaScript outright and continue to use the application to their liking. My old boss and I argued the same thing when I suggested we standardize the client code and support complete accessibility by functioning without Javascript.
If you had said semantic markup then I would have agreed with you - but that is not equivalent to validating against the w3c.
That gets even more complicated but thankfully that is more concerned with the web page/site side of things. Although I believe I use the proper semantic markup even within my application design. Very little use of tables except when listing records and accessibility was something I constantly kept in mind. Using labels, accesskeys, etc. There is more to it than that, I admit, just incase someone wanted to jump on me about how it's more indepth. If you still feel you can suggest a fix I'd be more than happy to show you the application and have you peak at the XHTML markup and make corrections.
You also said tests have no bearing on software quality - this is actually something that has demonstrated in multiple studies over and over. Tests correlate with software quality very closely.
I said that? I'm not sure if that is what I meant *exactly*. Of course testing has an impact on quality. Without testing how do you prove the application is ready for use?
If this thread has taught me anything, is that developers have much easier time discussing implementation than design
Implementation either works or it doesn't there is no middle ground, other than to accomplish the same thing with less lines of code or whatever, so yea, it's no wonder eh?
I dunno...I didn't have a hard time with this conversation...it just took me a while to realize where everyone else was coming from and then it became apparent why there was so much disagreement and little benefit coming from it all.
Would you rather have a page that takes 15 seconds to load that does what you need to do, or a page that loads in 5 seconds that does not meet your needs
Your missing the point. What if I could deliver the exact same page that did everything yours did but 10 times faster?
Users and site owners will tolerate most of the supposedly negative things on lists like that if they get the functionality they need.
People will tolerate speed to some degree...but there are more reports backing the fact that you have very little time to capture/please your audience. Google is largely successful because their simplicity in design and the fact their search results were returned in milliseconds not a couple of seconds. Yes I know they also changes the face of search using page rank to result in better results but I remember Leo Laporte advocating Google when they first came out because of it's speed and everyone calling in and agreeing the speed was awesome, not really mentioning the relevancy of the results.
Relevancy is expected, speed is the benefit of doing things right. I think you've spent to much time playing in open source. Paying customers will absolutely demand your application speeds up or they'll threaten to jump ship to another product.
Look, "good" does not mean perfect -- it means better than most of the other things like it. That's why I have said from the beginning that what makes applications successful includes some important things beyond the technical design stuff. I think jspro2 is probably closer to the important stuff when he talks about understanding users and the domain.
Thats rich...it's only more important because you share the same thought process.
Personally they are all equally important. Again if we have identical widgets in every way but mine breaks less, has less bugs, responds faster, which do you think is going to win the race? Similarly, if you fail to meet your end user requirements, it doesn't matter how pretty or well designed the applicaiton is, it's going to flop. Just as it's justified to say if you do not market your widget and no one knows it exists, you absolutely will not prosper financially/commercially. All three are equally important.
Cheers,
Alex