aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes How to measure a designs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "How to measure a designs "goodness"" Watch "How to measure a designs "goodness"" New topic
Author

How to measure a designs "goodness"

Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
There's a discussion in another thread on what makes a good design. But how do you measure how good a design is ? How do you convince your manager that you did a good job by creating a "good" design.
Mostly I read good engineers knowing instinctively what is a good design... the absence of code smells telling them that a design is good. But how do you convey that to your manager - tell him that the code doesn't smell ?!?
Has anyone had any experience with objective measures such as code metrics ? Are they useful ?
thanks,
D
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I don't think that this can be done automatically. In my experience, metrics can't tell you wether a design is good, they only can give you hints for specific problem candidates. I would bet that knowing the metrics used, I can produce a horrible design which still would pass the metrics perfectly (the other way around might be harder, but for some metrics still possible).
The only ways I know how to tell wether a design is good is
- letting it review by someone who you trust can tell, and
- letting time show wether you and your coworkers are able to understand and maintain the system
Well, I guess this didn't help much...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
BTW, what is your reason for wanting to?
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
I think I make good designs, however we do not do design or code reviews in out team, so I think sometimes I don't get the recognition for the good work I do. I know the answer should be to "do code & design reviews" but that is a subtatntial shift for our group, one that I as a junior member of the team do not feel I have the auhority to bring about.
D.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Measuring goodness may not be critical, but knowing what you call good is critical.
What if the members of a team respectively believe the most important thing is tight code with the fewest lines, OO purity, usability, small memory footprint, extensibility, Java performance, platform portability, and fast database access? Which property will the end product have? None!
McConnell's Rapid Development book sites some studies that indicate developers can write to a handful of such goals, but when you get too many they start to conflict and the result has no focus.
What if the team gets together and agrees on a vision before they start? I'm betting they can focus on the top four or six values and make them shine through on the final product.
[ April 29, 2003: Message edited by: Stan James ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
The main problem I have with most designs I come to work on is maintainability - they are a real mess - very difficult to understand, lots of duplication. I guess I like to think my code is better than this.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4462
    
    6

Originally posted by Ilja Preuss:

- letting time show wether you and your coworkers are able to understand and maintain the system
Well, I guess this didn't help much...

On the contrary, I think you are right on the money there.
As Frank said in the other thread, design is all about the choices that you make. If you make good choices, your code will be able to accomodate changes in the future with minimal pain and suffering (you might even cause some some "shock and awe" because of it ).
Sometimes, even an initially good design will not lend itself well to modifications. It all depends on what the new requirements are and how well they fit into the context of the original design. If the new requirements are outside the original context, then your initially "good design" could very well be invalidated.
This is why I think it is important for us as developers to become familiar with as many different design patterns as we can and become adept at refactoring from one design pattern to another. In the end, I think that the "goodness" of a design will be judged by how well it stands up to time and changing requirements.


Junilu - [How to Ask Questions] [How to Answer Questions]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to measure a designs "goodness"