May 16, 2008 at 8:47 am
What's more important: quality or consistency?
Yes.
There's science to applications and database development, and then there's art. There's function and there's form. Great applications / databases somehow manage to do both - and some of those manage to do it on time or early; at or under budget.
What are those people / teams doing differently?
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
May 16, 2008 at 8:51 am
Interesting debates and comments here.
Both are important, and the code has to work. Good/bad, fast/slow, ANDI standard/old style, it has to work. If it doesn't work, it has to be fixed.
However, the reason I think consistency is first, and why I think most people agree, is that people come and go, we have to work on each other's code, and most importantly, we want to build quality code, so we need to be sure everyone works towards that the same way.
So if you get everyone to start coding consistently, then you can change those consistent needs to reflect better quality. It might be something like changing temp tables to CTEs and slowly refactoring code.
How do I do this? In the past it requires taking a few days to dig in and see how things work. Not only what I need to do, but also seeing what other people do.
Then you have a meeting. You need to sit down, present what you think are good and bad quality ideas, let everyone have input, and then agree as a group how to name things, style things, tab counts, alias, etc. Everyone has to conform to the same ideas, and then you need to update this as you find new situations.
You also have to make everyone aware that if they hit a new situation, say the first UDT, that they call a quick meeting, or send a round of emails, and then agree on what everyone should do.
It's important that you are flexible over time, and that anyone can suggest better ways, but the most important thing is for everyone to be consistent, at least in my view.
May 16, 2008 at 8:52 am
I vote for quality. Two years ago, I had to tackle a whole system of code that was very consistent, but the code was a nightmare! It took a long time to change the basic functionality and performance of the code. I think it's a lot easier to implement consistency on code that's well-written to begin with.
Of course, the hardest part is getting all the developers to agree on the best standards - each one is adamant that their style is the best. In two years, I have not been able to work out a compromise on the coding style of one of the developers - whose style is almost the exact opposite of anyone else's!
May 16, 2008 at 9:01 am
So what is consistency and what is quality?
Consistency as I understand is the basis for formatting, naming and where the description header goes. Maybe how and for what comments are utilised.
Quality is well-performing code, easy to read and as short as possible within these constraints.
As such I think a lot of persons here understand that consistency is a subset of quality. And quality without consistency is not possible.
Some mentioned that they prefer quality - what do you understand as quality that is not given in your understanding of consistency?
May 16, 2008 at 9:20 am
Maybe I mis-understood the question. If you are starting a new project, then yes, the first step would be to establish the standards, and start coding in a methodical way, which will lead to quality.
I guess I have come into departments and had to pick up code that has been around for years, and had to build on that. The naming convention, etc. is minor compared to convoluted code, in my opinion. So I would rather start working with quality code and make it consistent. (and quality code will be internally consistent)
Which is not to say that I would continue to let developers each "do their own thing". In the end, you have to have both.
May 16, 2008 at 9:32 am
I agree that readability and consistency go hand in hand, and are a prerequisite to really quality code. Without some agreement by participants to some consistent standard of style/format the code quickly becomes unmaintainable.
In a former life one task I had was to try to figure out why some legacy Fortran-based rocket code wasn't working well when my predecessor ported it to the latest version of Fortran, which has C-based constructs. When I inquired, it turned out the engineers who were running the code, who were certified eggheads, were simply turning off/ignoring the compile errors!
When I then looked into the basic code and started structuring the spaghetti code into lasagna squares it became obvious the original programmer had named some arrays with words which were now reserved words. This would have been prevented if anyone had been given the task of going through the code and renaming all the variables with appropriate prefixes.
May 16, 2008 at 10:18 am
When I was consulting, the first thing I would ask for when I arrived at a new workplace was a copy of the coding standard. On the occasions when I was told that there wasn't one (which was often), I would start by analyzing existing code to see what my predesessors had done. On several projects, I have asked for authorization for a complete re-write, and in a few cases, I was able to get it.
The best scenario I encountered was at a large pharmaceutical company. When I got there I was given a coding standard, a full data dictionary, and an up-to-date ERD. I thought that I was going to faint. The worst was at a State agency where I just got blank stares and quizzical looks. When I left that position, I left a full set of system documentation for my successor. He's still there, and apparently curses my name only infrequently. 🙂
May 16, 2008 at 10:48 am
Quality is difficult to measure because environments are dynamic. "Quality" code can be useful and correct one day and wrong the next. It can be applied to code design to promote productivity.
Consistency get's my vote. It is the backbone of good programming because it promotes logical outcomes.
May 16, 2008 at 12:14 pm
Following a consistent style is an important part of any system for several reasons:
1. It makes it easier to figure out what the last person was doing.
2. You don’t have to spend a lot of time trying to figure out how a procedure works.
3. It makes it easier to spot mistakes and bugs.
4. It makes it easier to spot bad developers, because they can’t hide bad code with a bad coding style.
Using a consistent style doesn’t cost extra; it costs less and produces better systems with fewer bugs and lower maintenance costs. The fact that it is still possible to produce bad code in a consistent style is not an argument against it. In my experience, the bad code is usually the hardest to read, because it is created by a disorganized mind.
Imagine if every electrician wanted to use a different style for wiring. “I like to use the white wire for the hot; I don’t care if everyone else uses the black.” What would you think of a pilot that didn’t like to use the pre-flight check-list because it slows everything down? Or a doctor said there was do need to wash his hands before operating because they can always cure the infection with antibiotics.
May 16, 2008 at 3:59 pm
Knut Boehnert (5/16/2008)
...Then right now I am in a code heap documentation from someone else. While consistent the readability leaves much to ask for. It looks like the code was written on a screen 50" wide and 5 " high. Very compact to the point where it is a block with no real visible structure. Sure, the Select and From and Where parts are segregated but that's about it. ...
Knut, I've got you beat. The canned views in our ERP system are a single line. I don't know how long the longest line is, I don't want to know.
I find the best way to deal with this is to use TextEdit, an excellent text editor, and do a find/replace, replacing commas with "\t," (that's actually backslash n, backslash t: apparently the board here doesn't like the n). It breaks the lines up and indents the code at the same time. You'll have to do some work if there are functions in the code that have commas, like datepart, but it's a heck of an improvement.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
May 16, 2008 at 5:04 pm
I would say quality, although there are some areas where consistency might be appropriate.
Consistency is the enemy of improvement. When consistency is given primacy over quality the quality has a powerful tendency to stagnate. It has knock-on effects outside of the code, too. It tends to encourage the promotion of "control freaks" into positions of authority (after all, they follow the rules and don't but heads with their managers through trying to do things differently0which exacerbates the long term problems.
Where you have quality as the goal you have a constant interchange of ideas as people see others' work and get new ideas from what seems to work bes for them. Sometimes it takes longer and there will always be some people who have different ideas of what is the best quality. As soon as you come down on one side or the other you stop that interchange and damage the morale of the one who "lost".
The mainframe application development world was paralyzed by out of date coding standards and software that could never improve.
See where that gets ya?
May 16, 2008 at 5:38 pm
I'd follow a bit on what Jamie said: consistency tends to breed quality.
I disagree. Consistency is the long term enemy of quality. Consistency breeds stagnation and prevents the adoption of quality improvements.
I have been a developer for 30+ years now and almost everywhere I've worked in the last 20 years has had out of date standards based on obsolete information policed by people who have no recent coding experience.
Case in point - internal Cobol sorts.
Many places banned these in the mid '70s because they were notoriously inefficient compared to stand-alone sorts. By the late 70's Cobol had been changed to call the hooks into your stand-alone Sort package instead of its own inefficient routine. It made a cobol internal sort considerably more efficient than 2 programs with a sort between and rather easier to read and modify, too; yet 20 years later I was still coming across sites that banned internal sorts.
Another case in point from the mainframe world. When SQL first started moving into the mainframe world it provided a challenge to standards writers because it was a new technology; but they recognized some aspects of it and decided to make it fit what they knew so many shops required that all SQL calls use Select * and have a record layout coded for the results that every programmer could then use when accessing that table/view/procedure etc...
At a stroke this wiped out some of the greatest advantages of SQL and caused HUGE amounts of unnecessary work because every time a column was added or changed EVERY program using that table for ANYTHING had to be updated and that created hugely complex implementation problems while dozens of programs had to be simultaneously implemented just because someone thought that consistency was more important than quality. Millions upon Milllons of dollars wasted.
That whole Y2K thing... from the 70s onward; when I first started work in the industry I was trying to persuade my managers to start using 4 digit years on dates in new projects. Over and over I got the response that "this is our standard format and anyway, we're not going to be using this system in 30 years".
How many billions were wasted conforming to THAT standard?
If you rely on consistency to produce good code then your code will never get any better and you'll end up still coding "good" code when it hasn't been "good" for 20 years. And you'll never know it because you won't be the one coding it any more. You'll have a "standards" team consisting of the people no-one wants to work with and the people who want everything done the way they learned how when they were in school.
You might be down the golf club, bitching to the other company owners about how you're not getting the advertised benefits from the new technology, but it will never occur to you that the reason for that is that somewhere down the line your new technology is being shoehorned into the standards you set up when your company was a 100th of the size and you were actually involved in the coding process and all your staff are disgruntled and demoralized because they have all this new stuff and aren't ALLOWED to produce quality work with it.
May 16, 2008 at 6:34 pm
What's more important: quality or consistency?
The two are not mutually exclusive, nor does one spawn the other. And, if you want it done right, you won't let any time constraint interfere with either. I've been in shops, both startup and well seasoned... I've found that one without the other does nothing good in the long haul and can cause great damage in both the long and short haul.
It doesn't take any longer to write both quality and consistent code and will save hundeds of troubleshooting hours long haul and keep code from being kicked back in the short haul. Better yet, it'll keep short haul code from causing damage which must also be repaired in the short haul.
There's just no excuse for not doing both right the first time and the DBA, even a new one, needs to gently get people used to that fact. Same thing goes for Lead or Senior Developers and Managers. Do it right the first time or suffer the consequences.
And, I absolutely agree... whether you want quality, consistency, or both (you must want both), you'll need to invoke a set of written standards and the methods to enforce them. No way around it... people under pressure will always take shortcuts and unnecessary risks unless they are held accountable.
"When you come to a fork in the road, take it". (I think it was Yogi that said that...)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 16, 2008 at 6:52 pm
Perhaps Steve should have defined the meaning of the words "consistency" and "quality"! (But then the conversation would not have been NEARLY so interesting!) 😀
Some people equate standards with consistency, and I'll agree that obsolete standards that haven't kept up with the technology are at least as bad as poorly written code - maybe worse, since they prevent the use of "best practices" and the incremental improvement of the code.
I dont' think consistency has to be as rigid as the standards I've experienced in other shops I've worked in. But having worked in shops with few or no standards, I do have to say that properly written ones are a god-send. I think the problem lies in becoming too specific and detail-oriented. In one standards committe I was on at a shop that shall remain nameless, we spent an entire hour discussing how a single field should be named - all because one person wanted it done exactly the same as the way "they" did it; no compromise possible. That's an extreme case.
I think that excellent programmers have habits that are based on a consistent model, but that model will change over time as new technologies come along. An exceptional shop has a similar model - firm where it needs to be, but flexible enough to keep up with our ever-changing industry.
For instance, a bad "standard" might be something like "all field names will be less than 20 characters", where a good "consistency rule" might be "all field names will be descriptive enough to be recognizable, and of an appropriate length for ease of maintenance". It's about guidelines, not control, IMHO. I personally prefer to use upper and lower case, and underscores. A programmer I work with doesn't like the underscore, but uses upper and lower case. Someday I might work with a programmer that uses only uppercase and the underscore. Does it matter? Not if the field names can be recognized as descriptive of the field data, so we all three would fit into the consistency framework.
Consistency is, I think, an indicator of organized thinking. Programming with regard to the person who follows you and will need to maintain your code is an indicator of the ability to plan ahead. I believe both of those qualities will lead to higher quality code. But by no means do I think that consistency is the only indicator or precursor of quality code! There are other factors to consider (such as the "consistently bad code" mentioned by others in this thread!)
Maybe we should try to define what else is needed to produce quality code? That could keep the thread going for days! 😛 :hehe:
Steph Brown
May 18, 2008 at 6:35 pm
In the context of commercial code... Quality is consistency.
If code can be written by developer A and in 6 months developer B can pick it up and feel at home with it you have quality code.
Super optimized, hard to read or understand code is bad - no matter how 'kewl' it is.
Remember KISS!
Viewing 15 posts - 31 through 45 (of 75 total)
You must be logged in to reply to this topic. Login to reply