• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to measure a designs "goodness"

 
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
BTW, what is your reason for wanting to?
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic