Page 2 of 7

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 6:41 am
by Eran
PS - I don't think is helpful to make generalizations about nationalities.
I apologize if I offended anyone. I am an American citizen myself though I've been living abroad for a long time now. I was trying to pass an opinion on the flux of agile methodologies that take things too far, but perhaps I didn't convey it in the right manner.

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 11:03 am
by VirtuosiMedia
Might it not be more useful to categorize the different types of design and then evaluate each separately? IMO, code base design, user interface design, and feature design are all separate fields (and I'm sure there are more than just those three), though at times they may have overlapping concerns. If you can evaluate each subset of design, it becomes easier to quantify the quality of the overall design.

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 11:14 am
by inghamn
At the risk of getting even more philosophical than we already have.....

Alot of the disagreement is coming from the definition of 'good' as it pertains to design.
PCSpectra wrote: 1. Lines per function, class, module?
2. Memory foot print (RAM)
3. Average profiled execution time
4. W3C validation
5. Level of accessibility
6. Level of support for internationalization/localization
7. Summation of bugs per 1000 lines
8. Summation of security holes per 1000 lines
9. Summation of time required by developer to implement new features, fix bugs, etc.
Lists like this are trying to measure 'good'. However they don't really point to much explanation of what the target of 'good' is. Maybe if we first start with a more general description of good, we can then move onto how we could then come up with metrics that address that definition. And finally use those metrics to asses various software.

It seems like to define good you have to use phrases like: "Easy to extend","Functions Correctly","Is Popular".
For my part I usually work by defining "good" by putting things in order of priority:
  • Functions correctly
    Quick to develop
    Easy to extend
    End Users Like it
Only once we define "good" in general terms can we start looking for metrics to apply to software.

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 11:43 am
by alex.barylski
There are conceptually infinite designs for a piece of software. But in reality, of the hundreds of blogs, forums, CMSs, etc. -- only a few are actually very popular. Many on that list would be considered to have badly designed code by some here. My thesis is that the code is not badly designed, but actually may have some interesting things about it that might be helpful to know.
Precisely. Which is exactly why I suggested focusing on "tangibles".

In my experience, the better the design (whether it be MVC or do-hickey) the better the overall technical quality of the application.
And I think there is disagreement what is relevant and what is irrelevant. But if you would like this thread to be only about the design of the code without any discussion of features, that is your call in your thread.
I think in the previous thread certainly there was confusion. I was personally refering to tangible qualities of a project which are actually quantifiable, facts which cannot be argued or debated, numbers which might be used in a quality metrics standard, such as whether the pages validate against W3C, etc.

pytrin apparently means intangibles, like unit testing, etc. Where as you and jshpro2 seem to focus more on quality from the business side of things, in how well the project solves the problem domain.

All of these are/were valid arguments in their given context I suppose. The problem is, design patterns can be argued until your blue in the face, whether unit testing helps is highly debatable, if a software application solves your users problems can only really be tested once you go live with an application and develop a commercially successful software system/community.
As I have said, most of those "metrics' are just opinion -- except the test coverage. You might as well add "in a way I like" to the end of most of those statements. It is not that opinions about those might not be interesting to hear. I just think there are some better, more objective metrics.
That's twice you have said that and twice you have not bothered to elaborate.

There is no 'opinion' involved in gauging the quality of an application design whether benchmarking, validating against W3C, memort footprint, etc. While they are not directly indicative of good design (you could write really bad code that executed like greased lightning but produced buggy results) in enterprise applications it is unlikely this is the case.

The metrics I am speaking can quite simply be summed up in the following: Assume you have two indentical applications. Exacting in every way from interface to DB schema, there is no visible difference from the end user perspective and they solve the *exact* same problem.

Given the two applications, which would you pick:

1. The on that performed better (used less CPU cycles)
2. The one which used less memory (smaller system footprint)
3. The one which was historically more secure (less security exploits over it's life time)
4. The one which was more stable and less buggy (less reported bugs over it's life time)
5. The one which had fully validating pages with no exceptions
6. The one which was fully internationalized/localizaed (not just language translation)
7. The one which was fully accessible from a client side perspective (more of the application worked without JS enabled)

Answer these type of questions and you get a clear sense of that kind of quality metrics (which are/should be undisputable). I mean if you insist on using the application with more bugs, security holes and problems, than by all means, giver'

As a professional software developer I certainly wouldn't :P
Might it not be more useful to categorize the different types of design and then evaluate each separately? IMO, code base design, user interface design, and feature design are all separate fields (and I'm sure there are more than just those three), though at times they may have overlapping concerns. If you can evaluate each subset of design, it becomes easier to quantify the quality of the overall design.
Are my posts to long to read through touroughly or something? Is this not what I have been advocating? :P
Lists like this are trying to measure 'good'. However they don't really point to much explanation of what the target of 'good' is. Maybe if we first start with a more general description of good
A more general description of good? That is exactly what is causing the problem. If it's too general it's to subjective. I think my list is the only tangible way to prove quality over mediocre. There is no debate given the question I just gave.

Ask yourself, given two identical applications in every way...which would you chose given the list of standard metrics above? And don't change the subject or try and sway off topic, remember I said two otherwise identical applications (from the end user perspective) but one is technically superior, which do you chose?

From experience I can tell you that it takes a tremendous amount of work to make an Internationalized application, one that consistently validates, runs faster, etc, etc. Most of these metrics can *only* be achieved with a good underlying design (I happened to follow MVC the best I understood given the problem domain) that is to say, when you follow no design (phpList, WordPress, etc) you end up with bloated buggy software that "technically" speaking performs significantly poorer.

Ignoring the subjective arguments, such as "does it solve the users problems?". That is irrelevant in this dissucssion (my version anyways) as it's assumed we have a crack marketing/sales team who have dictated development from day one to solve exactly the problems set forth by our clients.

Let us focus on strictly the tangible metrics, so when two developement teams are writting an identical project, there is a quantifiable way of proving (without a dought) which is of the higher quality; aka standards compliant.
It seems like to define good you have to use phrases like: "Easy to extend","Functions Correctly","Is Popular".
That is very subjective. Everyone will have a different answer. And again, IMHO an application that runs faster, uses less memory, etc is going to be easy to extend, enhance, refactor, etc...by virtue of the fact it meets the above metrics. Large monolithic applications are not easy to extend, they are brittle and hard to unit test because of bad design choices (ie: WordPress). As a side effect these applications run slowed and have more bugs as well.
Only once we define "good" in general terms can we start looking for metrics to apply to software.
That is why I have been focusing no tangible metrics which are undisputable...you will *never* define "good" in "general" terms...the day you figure that out I will hand you the nobel peace prize because you also likely found the key to world peace. :P

You will never get an entire room to agree on such a vague description. However what I can tell you, is that as each "opinion" passes or exceeds the tangible metrics I have given (about 10 times now) such as validation, more bugs, less security holes, etc...then it becomes safer to assume that one given design works better than the next.

If design ABC consistently results in faster code, less bugs, less security holes, better stability, overall performance...the it's probably safe to assume the design ABC is better than design MVC and so on.

Cheers,
Alex

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 12:29 pm
by alex.barylski
Seems what we have here is multiple opinions all targeting different goals.

1. I was aiming at quality assurance metrics.
2. arborint/jshpro2 were refering to the quality determined by an end user
3. pytrin was focusing on the architectural design quality of an application

Personally I think debating on best practices or architectural design is helpful but you'll never agree on a standard until there is quantifiable proof that one design works better than the next by consistently meeting or exceeding a set of standards or metrics.

While I agree that list I supplied is not directly indicative of quality software, I believe that given two identical applications which solve the same problem, at some point these tangible metrics enter the scene and may be used to further determine the overall quality of either application. Certainly I would favour the application that ran faster, less bugs, etc.

Performance admittedly means nothing if the software doesn't solve problems. Whether you write a for loop or a while loop because one is faster is irrelevant, but when two identical applications are compared I believe it's justified to begin comparing tangible metrics.

While there are never going to be two identical applications, many of those metrics will still apply.

Hopefully this clears up some confusion. :)

Cheers,
Alex

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 12:40 pm
by inghamn
I terms of importance in defining "good" for my applications, I put performance, memory usage at the very bottom of the list. Performance, for me, is the absolute least important thing I can think of. Much more important is whether the code is easy to understand quickly. That way I can make the modifications I need to and move on.

What's obvious is that everyone will have different priorities in terms of things needed to define "good"

So, I guess my full list of priorities that I can use to define "good" is:
Functions correctly
Quick to develop
Easy to extend
End Users Like it
Runs Fast

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 1:00 pm
by alex.barylski
Performance, for me, is the absolute least important thing I can think of. Much more important is whether the code is easy to understand quickly. That way I can make the modifications I need to and move on.
Ditto...but the best design:

1. Allow a programmer to make changes faster, easier, etc
2. Allow the application to scale from one user to a million users with less hardware
3. Offer better security measures to prevent malicious use
4. Offer better stability and usability, etc

A good design in my experience will offer all those benefits you speak of and many more, including the tangibles such that I have indicated.

Again these metrics are not directly indicative of good design but they should be a consequence of good design. ;)

Let us assume that each of us have a idea as to what constitues "best" design practices -- which I promise you we all have differing opinions on this subject. How else do you prove which design is best?

By comparing the overall result against a table of metrics:

1. If application A performs better than application B
2. If application A has less bugs per 1000 lines that application B
3. If application A has less holes per 1000 lines that application B
4. If application A uses less memory on average per request than application B

If given a table of metrics to compare the two applications against each other if one consistently scored higher than the next, would you not conclude that, that individual's best practices, design, etc are likely better than your own? Of course people will defend their opinion until their blue in the face but being stubborn is not exactly the best way to improve an existing design or application.

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 1:09 pm
by inghamn
It would rely on what importance I placed on each of the metrics. Each of the metrics are there to measure something deemed important. The importance of each of those somethings is going to vary from person to person.

I don't think I would agree with the order of the following list of metrics.
PCSpectra wrote: 1. The on that performed better (used less CPU cycles)
2. The one which used less memory (smaller system footprint)
3. The one which was historically more secure (less security exploits over it's life time)
4. The one which was more stable and less buggy (less reported bugs over it's life time)
5. The one which had fully validating pages with no exceptions
6. The one which was fully internationalized/localizaed (not just language translation)
7. The one which was fully accessible from a client side perspective (more of the application worked without JS enabled)
It looks like, to you, performance is the number one key to good. I would much rather see an audit of the length of variable names ($x and $c just don't mean anything to me.) Also it would be important to me to audit the lines of code between comments. Uncommented code is nasty to work with.

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 1:17 pm
by VirtuosiMedia
I still think everyone is comparing apples and oranges in terms of design. Don't you first have to establish what kind of design you are talking about? I personally don't think that end users' satisfaction should have any part in a discussion about whether or not to use MVC because they deal with different aspects of design that should be dealt with separately. There should be a separation of concerns because the metrics for evaluating each aspect of design are going to be vastly different.

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 1:36 pm
by alex.barylski
It would rely on what importance I placed on each of the metrics. Each of the metrics are there to measure something deemed important. The importance of each of those somethings is going to vary from person to person.
That why I suggested a technique similar to SpamAssassin in how it deals with spam. Every message starts at zero points as each test it fails it gets a value added to it. Once you pass the specified amount, you fail the test.

The importance of each is very subjective, and performance is no where near the top of the chart. I would priortize security and then bugs as number one and two.

You could take a communit vote on which were the most important and base your standards calculation off a general consensus. Although I think most would agree that security and bugs are probably most important to the overall quality of an application, no?
I would much rather see an audit of the length of variable names ($x and $c just don't mean anything to me.)
That could be a factor as well, absolutely. You could even include things like formatting and whitespace as part of the overall summation of points.

As time went on and it became clear which tests resulted in the overall highest quality, the weighted values might shift to accomodate the importance of each factor. So personal bias is eventually removed from the equation.

For instance, I personally feel commenting is overated but someone else might argue otherwise. After a period of 12 months if their application consistently beat my own, I would certainly consider making comments a higher priority.

Of course, priority numbers could be adjusted for your inhouse development and metrics tested to verify that software was being developed according to your inhouse standards (which is what I do right now) but ideally you would develop according to a standard which was dictated by *real* best practices not just what you or I say are best practices.
I would much rather see an audit of the length of variable names ($x and $c just don't mean anything to me.)
There is clearly some confusion going on, yes. I am speaking strictly of quality assruance metrics whereas others are speaking in more broad terms such as design, etc. The problem I have with disscussing design, is it's never clear which is actually correct as there are no static targets to aim for. I believe the more tangible tests one strives to pass or exceed, the more that will drive your design in a positive direction.

While performance might be a moot point, keeping it in mind certainly won't hurt, as long as you understand the consequence of premature optimization. Keeping things simple often results in code that will execute faster, is the whole basis behind that argument, not that using known hacks for speed is a good practice. I didn't mean that at all.

Cheers,
Alex

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 2:13 pm
by josh

Code: Select all

 
exit();
 
The next best design.

It executes nearly instantly.There's absolutely 0 coupling. It is easier to refactor then anything you will ever write. It is amazing, my user's will use it and like it*

Before you call me ridiculous realize all I'm saying is you guys are still arguing implementation. Design happens on a whiteboard, following increments of analysis. Good design = software that not only models your user's conception of reality, but also does so in a way that allows you to refactor that reality ( as per the philosophy of holism that says you actually do not understand what it is you're creating). When (not if) your perceptions of reality change.

If the reality you are modeling _is_ software development, then your code quality metrics would be directly indicative of a good design. Design = plan[1]. Why is it that programming languages can still be successful without being turing complete? Why is it that some of them, for instance the scene navigator in Adobe Encore ( which is a programming language, yet ) can not be turing complete but sells better then some vendor languages that are on the hand, turing complete ).

Is it because they model the problem domain of a specific niche in a way that matches reality? I know seems crazy right. Like arborint said, since design means plan, and ultimately your plan is to please the end user ( unless you're just "playing" ), then to have a good design you must first of all model the actual customer's reality. This thread has also turned into a bit of a flame war which is unfortunate, I stated my opinion and I was asked to elaborate, I pointed out there was entire books written on the subject if you really wanted the detail ( NO L. Ron Hubbard :P )

[1] dictionary
* Or I'll fire them!

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 2:23 pm
by alex.barylski
and ultimately your plan is to please the end user ( unless you're just "playing" ), then to have a good design you must first of all model the actual customer's reality. This thread has also turned into a bit of a flame war which is unfortunate
I don't think anyone is disagreeing or flaming. Each of us ias arguing different point or phases of the SDLC.

I am advocating a quality assurance standard using quantifable metrics...this would probably be evaluated post design but would indirectly test the quality of the design. Lets face it, a bad design is likely going to have many negative side effects, such as bugs, security exploits, poor performance, non-validation, etc. Whereas (what I was trying to say all along) a good design, will meet some minimum standards and great design would meet all of them.

I guess I see little point in arguing whether your interpretation of front controller is accurate according to the authorities on the subject, until you have some tests to compare against, was my only argument.

Otherwise design is subjective and it's he said versus she said.

What is the essence of good design?

1. A solid architecture
2. A carefully thought out file structure
3. A framework of simple classes which are very specific and easy to extend

I don't think anyone would disgaree with that assessment but it's difficult to get into deeper details without starting an argument. Does your front controller implement any kind of forwarding or do you rely strictly on redirects? Is it really required to have forwarding in your application, if not then maybe it's best not to implement it in favour of keeping things simple. How does the front controller dispatch to action controllers? Should they even be called action controllers?

Cheers,
Alex

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 2:47 pm
by josh
PCSpectra wrote:I don't think anyone would disgaree with that assessment but it's difficult to get into deeper details without starting an argument. Does your front controller implement any kind of forwarding or do you rely strictly on redirects? Is it really required to have forwarding in your application, if not then maybe it's best not to implement it in favour of keeping things simple. How does the front controller dispatch to action controllers? Should they even be called action controllers?
Good design INCLUDES good coding. Using or not using a FC doesn't make or break design I'm not sure what you're getting at. ( If you're writing software for the F22 in ADA, you gonna use a FC with a passive view? likewise you wouldn't use a low level language to address a high level problem) As far as I'm considered every thing everyone is saying is a _part_ or good design, so far no one has proposed a simple yes/no metric, other then user acceptance. People keep continuing to argue code quality, I've acknowledged that is essential to a good design, in essence your argument is then "the user has nothing to do with the design". So let's just agree to disagree there

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 4:16 pm
by allspiritseve
PCSpectra wrote:For instance, I personally feel commenting is overated but someone else might argue otherwise. After a period of 12 months if their application consistently beat my own, I would certainly consider making comments a higher priority.
Correlation does not imply causation ;)

Re: What is the essence of good software design

Posted: Mon Nov 17, 2008 4:31 pm
by josh
allspiritseve wrote:Correlation does not imply causation ;)
Very nicely worded. Humans create perceptions called ideas to resolve tension of cognitive dissonance. For instance the concept of "luck" is created because we perceived a pattern which created dissonance, we then create the concept of "luck" to explain it.
( http://www.rd.com/advice-and-know-how/h ... 27664.html )

Then we start reinforcing our beliefs through conditioning. The metrics spectra listed are side effects of a good design, but things are never that straight forward. If there were an algorithm to define a good design, someone would have automated it by now.

If a belief is held highly enough, humans will filter out, deny, etc.. counter evidence to avoid the uncomfortably of considering the dissonance. This is called confirmation bias / minimal justification principle.