May 21, 2008 at 1:13 pm
That depends on your definition of "Consistent", doesn't it? Consistent only means inflexible if you use definition # 4 below. Courtesy of dictionary.reference.com:
Dictionary.com Unabridged
con·sist·ent
–adjective
1. agreeing or accordant; compatible; not self-contradictory: His views and actions are consistent.
2. constantly adhering to the same principles, course, form, etc.: a consistent opponent.
3. holding firmly together; cohering.
4. Archaic. fixed; firm.
--------------------------------------------------------------------------------
[Origin: 1565–75; < L consistent- (s. of consisténs, prp. of consistere). See consist, -ent]
—Related forms
con·sist·ent·ly, adverb
—Synonyms 1. congruous, consonant, harmonious, conformable.
Dictionary.com Unabridged (v 1.1)
Based on the Random House Unabridged Dictionary, © Random House, Inc. 2006.
Steph Brown
May 21, 2008 at 4:24 pm
I think definitions 1, 2, and 3 are the ones to apply here.
How can you tell rejected ideas would ever be better or worse? Presumably someone rejected them because they weren't better. You can't forsee every possibility and you can't let experience that your ideas getting shot down prevent you from trying new ideas.
Better is a tough item to define. What's better? Faster? More efficient? Less resources? It's a judgement call all the time. If you think a GOTO should apply, bring it up. But I think that consistency means that everyone has to agree it is worth including in code.
May 21, 2008 at 4:35 pm
ntaylor (5/21/2008)
Jeff Moden (5/21/2008)
Properly done, written enforced standards won't prevent someone from trying something new,Again, though. How do you measure when it's being properly done? You can easily measure when new things go wrong but there is no known measure for when rejected ideas would have been better. Evidence always stacks up higher and higher against change because improvements are hard to evaluate and potential improvements rejected are impossible to evaluate.
Besides which: some of the other descriptions in your post suggest that you're really talking about quality standards and guidelines as opposed to consistency standards.
Consistency DOES = Inflexibility. Every element of flexibility is by definition a deviation from consistency and an admission that other things can be more important.
I disagree, consistency does not equal inflexibility... heh... "Besides which:" you were apparently talking about quality with your GOTO example.
Think cars.... consitency means that cars built in the U.S. for U.S. consumption all have a steering wheel on the left side of the car. Nothing says that you have to put the cruise controls on the steering wheel but you will need some justification for putting the steering wheel on the right as in mail delivery. Consistency says you must have some convenient way to get into the car... nothing says that you have to have 2, 3, 4, or even 5 doors nor whether they shall open vertically or horizontally. Consistency says a car usually has 4 wheels... better have a good reason for 3 or 5 wheels. None of those "consistent" things prevent flexibility for exceptions.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 4:38 pm
Steve Jones - Editor (5/21/2008)
I think definitions 1, 2, and 3 are the ones to apply here.How can you tell rejected ideas would ever be better or worse? Presumably someone rejected them because they weren't better. You can't forsee every possibility and you can't let experience that your ideas getting shot down prevent you from trying new ideas.
Better is a tough item to define. What's better? Faster? More efficient? Less resources? It's a judgement call all the time. If you think a GOTO should apply, bring it up. But I think that consistency means that everyone has to agree it is worth including in code.
We've got some pretty circular logic going on here...
We know the right decision was made to turn down the idea because the idea was turned down. How long do you think it will take for the people responsible to realize that turning down something new can never, ever be the wrong decision?
And how are you going to try new ideas without actually trying them?
"I think that consistency means that everyone has to agree it is worth including in code" I think that's what it means, too; which is exactly why it's almost impossible to change once consistence becomes an end instead of a means.
May 21, 2008 at 4:52 pm
Jeff Moden (5/21/2008)
ntaylor (5/21/2008)
Jeff Moden (5/21/2008)
Properly done, written enforced standards won't prevent someone from trying something new,Again, though. How do you measure when it's being properly done?
Consistency DOES = Inflexibility. Every element of flexibility is by definition a deviation from consistency and an admission that other things can be more important.
Think cars.... consitency means that cars built in the U.S. for U.S. consumption all have a steering wheel on the left side of the car.
Does it? Or does it mean that everybody has the same size wheels and the same size tires.
You can make a case that it should; then no-one needs to know anything about wheel sizes when shopping for new tires. They just buy the brand they want and it "just works". Allowing people to have inconsistent tire sizes means that people will have to know what size they're looking for and manufacturers will have to make multiple sizes for different cars.
That's exactly the sort of logic that standards committees use for maintaining consistency.
Nothing says that you have to put the cruise controls on the steering wheel
Standards committees have a powerful tendency to do just that sort of thing and a powerful motive for doing so.
They can't ever be blamed for saying "no" because there is no way to audit what was not done. If one "yes" in 10 goes bad they'll get stick for it and go more conservative. If 9 out of 10 things they turn down would have saved the company millions of dollars no-one will ever know. Which side do YOU think they're going to err on?
May 21, 2008 at 5:27 pm
Consistency didn't stop 20 inch wheels from coming out nor has it prevented the use of 13" wheels on some small cars.
Whatever... we could go on forever... our ideas of what consistency entails is obviously different.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 6:00 pm
ntaylor (5/21/2008)
If the SDLC etc provides for, and encourages, improvement then there is not a problem.
If the SDLC etc provides for, and encourages, improvement then you have acknowledged that quality overrides consistency.
Quality is about continued improvement. This is done best with consistency (which is not static). Think CMM ... eg. level 5 with demonstrated process improvement - done consistently.
May 21, 2008 at 10:29 pm
In an ideal world consistent solutions for all instances consistent with a problem type while the technology is static.
Only problems aren't consistent and technology is always changing.
They are not the same, they are not opposing choices.
Consistancy is a quality of a solution. But then again so are performance, Development Effort, Review effort, Readability and Re-Use.
Consistancy between solutions across problem types without assessment of the problems suitability to the template is getting into golden hammer territory.
May 22, 2008 at 2:11 am
This thread is getting so long I had to go back and check what the original question was! 🙂
What's more important: quality or consistency?
The definition of quality that I've always used is that a product or service meets or exceeds the needs and expectations of the customer, while the definition of consistency is that tasks are done in the same way or that products are products that are virtually the same.
On this basis, the answer is obviously that quality is more important. If the customer is not satisfied, i.e. the quality isn't good enough, then it doesn't matter how consistent the method of working is because you aren't going to be in business very long!
of course, maintaining quality usually requires following standards, which will generally lead to come consistency, but this isn't (or shouldn't be) the goal. Consistency is just a beneficial side-effect of aiming for quality.
Derek
May 22, 2008 at 6:18 am
They are both important, and hopefully quality brings consistency, but if you step into a situation where you have inconsistency and a lack of quality code, what do you tackle first? That was the original premise.
Making the decision doesn't mean it's the right one and you definitely have to guard against people assuming that. However consistency doesn't mean inflexibility. It tends in that direction and you have to fight against that, but it's not the same thing.
May 22, 2008 at 7:48 am
Jeff Moden (5/21/2008)
Consistency didn't stop 20 inch wheels from coming out nor has it prevented the use of 13" wheels on some small cars.
If consistency was considered more important than quality, or as being the prime determinant of quality, then it might very well have.
13" and 20" wheels are inconsistent with a standard of 14" wheels and if consistency is more important than quality then it WOULD have prevented those inconsistent sizes.
Just as I was told, over and over again, that 4 digit years were inconsistent with the company standard date format on files. In fact one manager told me that if I wanted to use a 4 digit year I could put in a request to change the standard, however in order to ensure consistency I would have to justify the cost of retrofitting every system to conform to the new standard.
When you value consistency over quality, if you measure quality by the amount of consistency then that is the kind of stupidity that bubbles to the surface.
May 22, 2008 at 8:40 am
I think we have to agree to disagree.
you're citing specific instances to show a general problem, but that's not the case. 4 digit years might cause problems, might not, might be a good decision or not. It depends on what you're doing and where. Can't speak to that case.
A 14" standard wouldn't prevent other standards from co-existing. If you look at it as either black or white, meaning everything conforms or not, I think you make the same mistake you're arguing about. You develop standards for an area and apply them as long as they apply. If they need to evolve, you do that as well.
May 22, 2008 at 9:10 am
Steve Jones - Editor (5/22/2008)
you're citing specific instances to show a general problem, but that's not the case. 4 digit years might cause problems, might not, might be a good decision or not.
That was never given any consideration; which is the point I'm making. When the standards were implemented memory was expensive and 2 bytes made a difference. By the time I started coding 2 bytes here or there didn't make the slightest bit of difference but nobody cared to change the standards because consistency was more important.
"4 digit years might cause problems, might not, might be a good decision or not" - those are all quality decisions, and quality was subordinate to consistency so the only decision that counted was whether they were all the same. The decision may have had quality reasoning behind it in the first place but once implemented as a standard it became locked in and took virtually a national disaster to change it. (OK - I presume: I was only there 4 years).
It depends on what you're doing and where. Can't speak to that case.
It didn't to the standards manager.
A 14" standard wouldn't prevent other standards from co-existing. If you look at it as either black or white, meaning everything conforms or not,
It has been my experience that when "consistency" is treated as more important than, or the prime measure of, quality then it DOES prevent other standards from co-existing and it DOES see standards conformity as a black and white issue.
May 22, 2008 at 9:18 am
ntaylor (5/22/2008)
Jeff Moden (5/21/2008)
Consistency didn't stop 20 inch wheels from coming out nor has it prevented the use of 13" wheels on some small cars.If consistency was considered more important than quality, or as being the prime determinant of quality, then it might very well have.
13" and 20" wheels are inconsistent with a standard of 14" wheels and if consistency is more important than quality then it WOULD have prevented those inconsistent sizes.
Just as I was told, over and over again, that 4 digit years were inconsistent with the company standard date format on files. In fact one manager told me that if I wanted to use a 4 digit year I could put in a request to change the standard, however in order to ensure consistency I would have to justify the cost of retrofitting every system to conform to the new standard.
When you value consistency over quality, if you measure quality by the amount of consistency then that is the kind of stupidity that bubbles to the surface.
I know I am probable beating a dead horse, but in the your example, your manager was incorrectly applying standards, if you have an existing system that uses 2 digit years, then any additions to that system should stick to that standard, but when designing a new system using 4 digit years would not be wrong or inconsistent.
For instance as a DBA when I go into a new job or inherit a new server, I immediately check the backup design. My baseline is Full Backups weekly, daily differentials and hourly tx logs for transactional systems. If these are not in place then I put them in place. Then as I learn more about the system I adjust. Sure it's not exact, but that is where I start for consistency and then I work on the quality.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
May 22, 2008 at 10:02 am
The last line from Steve's original poll was "I'm sure some of you have strong opinions on this, but if you walked into a situation, what are you more concerned with?"
ntaylor makes some good points - consistency can be taken to extremes and become a roadblock to quality, rather than a milepost along the road. (And I, too, have gotten the 2-digit versus 4-digit requirement - on a total system rewrite in the early 90's, where "it might break something" just didn't apply at all.) Standards committees, like all committees it seems, eventually become more concerned with their own existance than with their original task. However, it takes time and effort to get to that point! The trick is to find a balance - and stop the foolishness before it starts! :hehe:
So if you've been burned by the "consistency psychosis" in the past, and you are walking into a new situation / job / project that needs some quality, what approach do you take? How do you determine quality or lack thereof in the first week or two, and what steps do you take to begin upping the quality quotient?
I suspect that if most of thought about it, we have a consistent way of doing that...;)
Steph Brown
Viewing 15 posts - 61 through 75 (of 75 total)
You must be logged in to reply to this topic. Login to reply