Page 3 of 7

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 4:36 pm
by alex.barylski
Using or not using a FC doesn't make or break design I'm not sure what you're getting at
My point was exactly what you followed up with after the above statement. Whose to say when or whether one should use a fornt controller? It's subjective. The design pattern is flexible enough to be used for Avionics software so I'm not sure why would suggest otherwise.

Anytime an application has more than a single entry point a front controller almost implicitly enters the equation, it's the implementation or interpretation that will differ greatly.
Correlation does not imply causation
Are you a Philadelphia lawyer? :P

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 4:53 pm
by josh
PCSpectra wrote:The design pattern is flexible enough to be used for Avionics software so I'm not sure why would suggest otherwise.
Definitely. All I'm arguing is everything has to be in context. FC works given a certain design problem. No matter what any design problem traces back to a user problem, even if yourself is the only user you are considering. If you're only considering your own needs you're being selfish, but can still write a good design anyways. The thread was about the most fundamental or vital part of the design process though ( as per the definition of essence ). To say that the user experience doesn't at least overlap with that definition would be silly. I'm not saying I'm 100% right either, I'm merely saying we could write code generators that write code that satisfy every metric you listed, and I guarantee it would not produce a usable product except by pure statistical process of elimination ( put 5 monkeys in a room with a typewriter and eventually they'll write the entire works of Aristotle, this does not mean the essence of Aristotle was primate driven literature )

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 4:56 pm
by Christopher
PCSpectra wrote:Whose to say when or whether one should use a fornt controller? It's subjective. The design pattern is flexible enough to be used for Avionics software so I'm not sure why would suggest otherwise.

Anytime an application has more than a single entry point a front controller almost implicitly enters the equation, it's the implementation or interpretation that will differ greatly.
But according to your statement, the choice of using a Front Controller is mostly objective. When you have or need a single entry point then you use a Front Controller. There may be subjectivity in how you implement the Front Controller pattern.

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 5:49 pm
by alex.barylski
I'm merely saying we could write code generators that write code that satisfy every metric you listed, and I guarantee it would not produce a usable product except by pure statistical process of elimination ( put 5 monkeys in a room with a typewriter and eventually they'll write the entire works of Aristotle, this does not mean the essence of Aristotle was primate driven literature )
That is exactly the point. ;)

Sure you could generate fully validating XHTML but it doesn't mean it conveys the information correctly to end users. BUT you could write a document using garbage HTML and have it mean something to end users and mean nothing to search engines or whoever.

There is no denying that two identical pages one written according to a W3C standard and another written ad hoc using a WYSIWYG from the 90's -- which document would be perceived by a software professional as the better more professional version? Certainly there is no (or little) difference to an end user but we as professionals are supposed to be aware of these standards and develop accordingly.

Honestly, if your software can't pass a simple automated test that is trivial enough for a computer to determine...they you have probably flaked on a lot of other quality measures which are not as easily quantifiable as a W3C validation test.

It takes a lot of work to meet or exceed automated tests and I believe it directly reflects the capabilities of the developer(s) who wrote the software.

All of what has been disscussed here is important to me...conceptual design...user input you name it...I've been in this industry for a long enough time I understand the importance of each phase/stakeholder...

Cheers,
Alex

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 6:00 pm
by allspiritseve
PCSpectra wrote:Are you a Philadelphia lawyer? :P
No, but I'm a Kalamazoo College psychology major, is that close enough?

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 6:10 pm
by alex.barylski
Kalamazoo College psychology major
Stay away from me *makes a cross with his fingers* :lol:

Is there seriously a Kalamazoo College? Is it anywhere near Tuktuyuktuk? :P

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 6:41 pm
by josh
PCSpectra wrote:There is no denying that two identical pages one written according to a W3C standard and another written ad hoc using a WYSIWYG from the 90's -- which document would be perceived by a software professional as the better more professional version?
something we can agree on
PCSpectra wrote:Certainly there is no (or little) difference to an end user but we as professionals are supposed to be aware of these standards and develop accordingly.
something else we can agree on
PCSpectra wrote:Honestly, if your software can't pass a simple automated test that is trivial enough for a computer to determine...they you have probably flaked on a lot of other quality measures which are not as easily quantifiable as a W3C validation test.
also agreeable :-) see, we can get along ( actually, we can't :twisted: .. just kidding )
PCSpectra wrote:It takes a lot of work to meet or exceed automated tests and I believe it directly reflects the capabilities of the developer(s) who wrote the software.
Also agreed, but if you looked at all those tests and compared what they have in common as far as intention, and averaged that out over a set of successful ( as in sustainable over time, which implies user acceptance or some sort of funding ) then you could say you have the essence of good design. If you had angel investors as your only TAM, the essence of the design would still boil down to a human and how he/she emotionally feels about your software. Just because software has quality code, might run faster, etc.. don't mean your user is going to associate your product with positive feelings. One UI screwup or marketing blunder can cause your user to feel anxious, unsure, discontent, etc.. whereas modeling the user's problem domain / reality leads to a design that is richer in terms the user can connect with on a deeper level.

I like the idea in Eric Evan's book of simply explaining your domain models interaction to your target end user, and reading his/her face visually for signs of recognition / confusion. It's like playing marco pollo with body language to find the good design. Its objective in the fact that it relies on the collective subjectivity of ourselves. ( we are our own users sometimes ).

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 7:05 pm
by alex.barylski
Just because software has quality code, might run faster, etc.. don't mean your user is going to associate your product with positive feelings
Do you really think any of that is pertinent to the design of software, under the context of theory and design?

99% of the conversations had in this forum are about the implementations of design patterns, etc not about stakeholders and end user satisfaction. Honestly, unless you are like me or you and have intentions on releasing a product as your own, a dedicated developer would not be interested in any of the physchological factors that factor into the design of the application. That would more likely be delegated to the project manager then possibly articulated to the software architect would might then delegate duties to his/her subordinates.

Of course this is entirely dependent on the structure of any given company...but I know speaking from experience I was never interested in whether the product solved a problem...in fact I had little say in that regard I was solely responsible for making sure the program was as bug free, secure, validated, performed well, etc.

Like I said, each of us was/is focusing on entirely different phases of the SDLC.

1. Design in terms of architecture like pytrin is probably first
2. Design in terms of metrics and quality assurance would probably come next
3. Lastly you would have all of the user acceptance testing and ultimately at this point your program makes it or breaks it

I prefered to focus on the more tangible of the three because I know exactly what happens when you argue the implementation of a front controller...I've seen it a million times before. Nothing rarely constructive comes out of it unless the topic is started by someone genuinely interested in what others have to say and then, the conversation usually forks/hijacks in a flame war direction because I think I know better than you and visa versa. :) Not saying either of us are like this but I've witnessed this behavior in everyone so I wouldn't discount us either.

Anyways, if we agree that each phase is equally important and we agree that #2 is likely the most tangible...I ask what other metrics might a system (not nessecarily computer driven) use to determine the overall code quality?

My idea was to gather enough insight into quality metrics and implement a tool much like SLOCcount but more thourough. It might for instance tell you what files need to be refactored based on number of bugs over a given time in that particular module or function, etc.

If enough people used the tool and agreed to submit data to a central database, you would eventually be able to decide on standard metrics, like what is the ideal number of lines of code per function, class, module, etc.

Cheers,
Alex

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 7:27 pm
by Eran
I prefered to focus on the more tangible of the three because I know exactly what happens when you argue the implementation of a front controller...
When I said intangibles, I was definitely not talking about concrete implementation. The fact that you choose to use a FC at all means you've made a design decision, the specific implementation of it is less relevant to me.

When I started this thread I was trying to talk about the process a developers goes through when he start to work on an application. We are all familiar with the position - working against a complete specifications to an application, we start putting together the building blocks of the design. Whether the requirements embodied in those specifications will fulfill some users' real need is not something that is within our responsibility matrix most of the time. Some time we can offer input on that, but most of the time we need to implement against requirements handed to us from our employers.

How we choose to implement those requirements is what I call software design.

What you consider measurable metrics, Spectra, are not necessarily relevant to the specifications so they do not reflect design. Web 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?). The better the design is, the easier it would be to make optimizations when they are needed.

Also W3C validation has become a staple of almost hollow specifications. 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. Some of those validation rules are ludicrous - if an image has an "alt" property it is valid, even if that attribute is an empty? 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.
If you had said semantic markup then I would have agreed with you - but that is not equivalent to validating against the w3c.

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.

If this thread has taught me anything, is that developers have much easier time discussing implementation than design :wink:

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 8:04 pm
by Christopher
Well I am glad you guys agree on so much! :)

But then Hockey heads off on his lists and starts splitting up things in phases. I think the last list is backwards and most of the other lists above have very little meaning. They contain either aphorisms like "solid architecture." Or they have things are perennially meaningless like "fast." 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. Users and site owners will tolerate most of the supposedly negative things on lists like that if they get the functionality they need.

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.

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 8:09 pm
by Eran
Well I am glad you guys agree on so much!

That's developer camaraderie for ya :P

Chris, what about design fulfilling requirements regardless of what those requirements mean to actual users? you don't think the structure of code that fulfills a set of requirements can be called design? I'm pretty sure you can relate to the situation I describe in my last post. Is it really impossible to separate the act of converting specifications to code from the underlying meaning of those specifications to users?

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 8:20 pm
by alex.barylski
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? :lol:
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. :lol:

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

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 8:36 pm
by Eran
Dude...I can't believe you said that. My application pushes the boundires in terms of AJAX and javascript too and guess what?
What I meant by that is that validation should be taken in context. Some applications do not use the standard page-based navigation that web-sites are so well known for. Take Gmail for example, it fails validation miserably. Does it mean it lacks in design? it is simply not relevant in that context.
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.
But what if you entire interaction is based on drag and drop? some sites are bonna-fide applications that attempt to mimic real GUI using limited means (ie, javascript). Those sites were never meant to run without Javascript - does this imply bad design? or are those simply the requirements to fulfill users' needs?

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 9:00 pm
by alex.barylski
Take Gmail for example, it fails validation miserably. Does it mean it lacks in design? it is simply not relevant in that context.
Google is notorious for not validating...while it doesn't nessecarily say bad design it does demonstrate some ignorance.
ut what if you entire interaction is based on drag and drop? some sites are bonna-fide applications that attempt to mimic real GUI using limited means (ie, javascript). Those sites were never meant to run without Javascript - does this imply bad design? or are those simply the requirements to fulfill users' needs?
This is subjective, but, after 25 years of using computers and witnessing their evolution go from command line to desktop to over the top flashy desktop to web based applications, to web 2.0 applications which try and emulate desktop environments...I think the best applications are those which do not nessecarily require drag and drop. While it makes for an interesting sugar coating (ie: Google homepage for example has draggable dashlets -- which I have also implemented) I don't know.

To much AJAX and web 2.0 makes the application slow to respond. I've noticed a mjor slow down in Facebook's ability to render and as a consequence I've stopped using as much, and most of my friends agree it's slightly boggy and buggy, considering the JS frequently chokes and prevents you from posting a note to a friend.

I'm on the fence about that one. Initially my interface was quite complex and relied hevily on AJAX. It caused a lot of debugging issues and annoying problems with conflicting JS libraries. I simplified the interface over and over again to the point where I no longer "need" javascript and I think most would agree it's a much simpler interface. 4 or 5 primary tabs and thats it.

Can you give en example of when drag and drop would be a mandatory functionality?

If you were implementing a shopping cart and wanted users to just be able to drag and drop items onto a cart, I would personally recommend re-thinking that design and sticking with a traditional request//refresh/response approach while maybe offering the drag and drop as a option for those who are familiar with click and drag.

Cheers,
Alex

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 9:10 pm
by Eran
Can you give en example of when drag and drop would be a mandatory functionality?
I didn't say mandatory - I meant that this is the core of the interaction. Also, drag-and-drop is just an example you presented, there are plenty of interactions only possible with javascript. While those interactions could be converted to the old GET/POST/refresh model, often when developing an application its a secondary concern to support immediately the dwindling percent of people with no javascript turned on.

You want to deliver the best user experience first - and I would very much argue that user experience enhancements are just "sugar-coating".
If an interaction can be completed much easier and more intuitively than filling forms and submitting again and again, then it's a higher priority than supporting those without javascript support.