Forums Register Login
How to measure a designs "goodness"
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 ?
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...
BTW, what is your reason for wanting to?
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.
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 ]
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.

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.
Wink, wink, nudge, nudge, say no more ... https://richsoil.com/cards

This thread has been viewed 534 times.

All times above are in ranch (not your local) time.
The current ranch time is
Jan 19, 2018 15:53:27.