April 17, 2009 at 11:35 am
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience. One is not easier nor harder than the other. If you know cursors and procedural development then cursors are easier than set based. If you know set based and not cursors then set based is easier. If you know both then neither is harder than the other. It becomes a matter of which is best to use for a particular situation. I think it simply boils down to, cursors tend not to be the best choice because SQL Server is more optimized for a "Set Based" approach. I don't see that as making cursors "bad", just not your first choice if you understand set based development in a SQL environment. 🙂
April 17, 2009 at 11:52 am
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes whether you allow a developer who's lacking in experience to lower your expectations as an organization, or do you raise the skill levels of your inexperienced developers and teach them the best way to accomplish the tasks at hand to maintain high standards and meet high expectations?
April 17, 2009 at 12:00 pm
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes.....
Exactly! 😉 Assuming, of course, your organization has the time and luxury to do so!
April 17, 2009 at 1:19 pm
bruce.trimpop (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes.....
Exactly! 😉 Assuming, of course, your organization has the time and luxury to do so!
If you don't have the "time and luxury" to make your developers actually learn how to do their jobs properly, then you probably have neither the time nor luxury to employ developers in the first place.
I can't imagine a single other professional field where people would actually defend the practice of "we don't do it right, because we can't be bothered to learn how".
Imagine how you would feel if your physician told you that he uses bloodletting instead of antibiotics, because antibiotics are complex, and bloodletting is "something that my nurses are already pretty much trained to do, because they know how to take samples for the lab".
Imagine if your cab driver spent a whole trip to the airport in first gear, because he was used to driving an automatic and "this is more similar, so it's easier for me to do".
In either of those cases, you would NOT excuse the behavior. So why do people excuse that kind of behavior in software devs? I don't. If the person can't write T-SQL competently, if they insist on "driving in first gear" (using cursors all over the place), they shouldn't take the job in the first place, or should lose it as soon as it's evident they lied on their resume.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 17, 2009 at 1:33 pm
bruce.trimpop (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes.....
Exactly! 😉 Assuming, of course, your organization has the time and luxury to do so!
OTOH if you don't want to invest the time and resources necessary into training your people then you can (1) hire only senior people who are already trained, or (2) prepare to spend more time and resources (orders of magnitude more) on the back end trying to fix issues that properly trained developers tend to avoid. 🙂 Training your people provides the luxury of "making your customers happy" which leads to the luxurious state of "staying in business".
April 17, 2009 at 1:37 pm
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes whether you allow a developer who's lacking in experience to lower your expectations as an organization, or do you raise the skill levels of your inexperienced developers and teach them the best way to accomplish the tasks at hand to maintain high standards and meet high expectations?
Training is a luxury??? I'm sorry, it is mandatory. If the company can't/won't provide it, then developers need to expend their own time and money in learning how to do their job better. It is part of their own professional development, keeping themselves relevant in the ever changing IT field.
April 17, 2009 at 1:43 pm
GSquared (4/17/2009)
bruce.trimpop (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes.....
Exactly! 😉 Assuming, of course, your organization has the time and luxury to do so!
I can't imagine a single other professional field where people would actually defend the practice of "we don't do it right, because we can't be bothered to learn how".
It truly amazes me how some peoples worlds are black and white. I'd love to live it that world. First, I was NOT defending the practice I was stating that some companies in the real world whether right or wrong do not have the luxury or time to do things "right" by your definition. They have obligations (contractual or otherwise) to get it done and have it work under given time constraints.
Imagine how you would feel if your physician told you that he uses bloodletting instead of antibiotics, because antibiotics are complex, and bloodletting is "something that my nurses are already pretty much trained to do, because they know how to take samples for the lab"
Ok how about this if you want to talk about medicine, a medic on the battle field can stop the bleeding and sow up a wound with 10 stitches but that patient will live and he can move on to the next patient, or he can take his time, "do it right!" and use 50 stitches while the next patient bled to death.
In my world I often don't have time to do a perfect solution, I have to do the best I can under the time/contractual obligations that I am presented with and get something that works to the customer. Could it be done better...given more time absolutely....does work the way it was delivered...you betcha!
Part of the problem with black and white arguments is they are rarely real world. They tend to exaggerate the opposite ends of the spectrum. The analogy is not one of blood letting vs antibiotics, it's one of antibiotics vs homeopathic solutions. Some would argue homeopathic is the better choice because of all the problem of over use of antibiotics causing drug resistance, homeopathic may be the "right" choice but it takes longer, and I need to get the infection under control ASAP!
My world exists somewhere in the middle and I've been doing this for a lot of years!!!
April 17, 2009 at 1:55 pm
Lynn Pettis (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes whether you allow a developer who's lacking in experience to lower your expectations as an organization, or do you raise the skill levels of your inexperienced developers and teach them the best way to accomplish the tasks at hand to maintain high standards and meet high expectations?
Training is a luxury??? I'm sorry, it mandatory. If the company can't/won't provide it, then developers need to expend their own time and money in learning how to do their job better. It is part of their own professional development, keeping themselves relevant in the ever changing IT field.
I absolutely agree, but I did not say training was a luxury. I said ...well you can read what I said. 🙂
What I'm saying is that while the training is going on I still have product to deliver. So I deliver the best solution I can today which is when it's due. Tomorrow I find out about some new whiz bang feature in training...great I'll use that on the next project, but yesterday's project with the old "not right" solution, that works fine by the way, is out the door. If I have the luxury of some fee time maybe I'll be able to refactor it!
April 17, 2009 at 2:07 pm
bruce.trimpop (4/17/2009)
Both arguments are relative to the developer's experience. One is not easier nor harder than the other. If you know cursors and procedural development then cursors are easier than set based. If you know set based and not cursors then set based is easier. If you know both then neither is harder than the other. It becomes a matter of which is best to use for a particular situation. I think it simply boils down to, cursors tend not to be the best choice because SQL Server is more optimized for a "Set Based" approach. I don't see that as making cursors "bad", just not your first choice if you understand set based development in a SQL environment. 🙂
Hmmmm...I guess that depends on what tools you're using and what you're coding. If you're coding a simple select from a half dozen or so related tables in a properly designed database (PK/FK RI etc), you can use a GUI query tool such as SSMS query editor to plop in the tables, check desired retrieval columns, add a filter or two and "SHAZAM!" your set based solution is done. I can't imagine anybody would argue that a cursor solution would be easier to write, understand, or maintain than that. I could imagine that a procedurally oriented person would need training in order to design the database properly in the first place, though.
April 17, 2009 at 2:39 pm
bruce.trimpop (4/17/2009)
GSquared (4/17/2009)
bruce.trimpop (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes.....
Exactly! 😉 Assuming, of course, your organization has the time and luxury to do so!
I can't imagine a single other professional field where people would actually defend the practice of "we don't do it right, because we can't be bothered to learn how".
It truly amazes me how some peoples worlds are black and white. I'd love to live it that world. First, I was NOT defending the practice I was stating that some companies in the real world whether right or wrong do not have the luxury or time to do things "right" by your definition. They have obligations (contractual or otherwise) to get it done and have it work under given time constraints.
Imagine how you would feel if your physician told you that he uses bloodletting instead of antibiotics, because antibiotics are complex, and bloodletting is "something that my nurses are already pretty much trained to do, because they know how to take samples for the lab"
Ok how about this if you want to talk about medicine, a medic on the battle field can stop the bleeding and sow up a wound with 10 stitches but that patient will live and he can move on to the next patient, or he can take his time, "do it right!" and use 50 stitches while the next patient bled to death.
I think the situations in which spending a little more time to develop your database code correctly puts people lives at risk are probably few and far between. I would be interested in hearing real-world situations where ensuring that your database code was correct resulted in someone's death. Or near death. Or papercuts.
In my world I often don't have time to do a perfect solution, I have to do the best I can under the time/contractual obligations that I am presented with and get something that works to the customer. Could it be done better...given more time absolutely....does work the way it was delivered...you betcha!
And when employers bother training their employees the quality of what can be delivered increases while the time to deliver decreases. It's a win-win. When you don't train employees the quality of work suffers and you spend a lot more time and money fixing things well after you're supposed to be done. It's not a recipe for happy customers.
Part of the problem with black and white arguments is they are rarely real world. They tend to exaggerate the opposite ends of the spectrum. The analogy is not one of blood letting vs antibiotics, it's one of antibiotics vs homeopathic solutions. Some would argue homeopathic is the better choice because of all the problem of over use of antibiotics causing drug resistance, homeopathic may be the "right" choice but it takes longer, and I need to get the infection under control ASAP!
Neither of those is the analogy. The analogy is about trained employees vs. untrained employees, happy customers vs. unhappy customers, a healthy revenue stream vs. bankruptcy.
My world exists somewhere in the middle and I've been doing this for a lot of years!!!
I don't understand this last statement. You seem to come out against training employees, but now you're "in the middle" somewhere. Just wondering what that means?
April 17, 2009 at 2:54 pm
bruce.trimpop (4/17/2009)
Lynn Pettis (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes whether you allow a developer who's lacking in experience to lower your expectations as an organization, or do you raise the skill levels of your inexperienced developers and teach them the best way to accomplish the tasks at hand to maintain high standards and meet high expectations?
Training is a luxury??? I'm sorry, it mandatory. If the company can't/won't provide it, then developers need to expend their own time and money in learning how to do their job better. It is part of their own professional development, keeping themselves relevant in the ever changing IT field.
I absolutely agree, but I did not say training was a luxury. I said ...well you can read what I said. 🙂
What I'm saying is that while the training is going on I still have product to deliver. So I deliver the best solution I can today which is when it's due. Tomorrow I find out about some new whiz bang feature in training...great I'll use that on the next project, but yesterday's project with the old "not right" solution, that works fine by the way, is out the door. If I have the luxury of some fee time maybe I'll be able to refactor it!
Actually, you did say it was a luxury:
Exactly! Assuming, of course, your organization has the time and luxury to do so!
And what works fine with a few hundred rows, can become a serious issue when you start to approach thousands or millions of rows of data. You need to plan for scalability in your code, not just for today. Cursors are not a scalable solution and it gets compounded when you start nesting them.
Training should be an ongoing part of any organizations development environment, and should actually be included in the development of products and services. It shouldn't be an after thought.
April 17, 2009 at 2:57 pm
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
GSquared (4/17/2009)
bruce.trimpop (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes.....
Exactly! 😉 Assuming, of course, your organization has the time and luxury to do so!
I can't imagine a single other professional field where people would actually defend the practice of "we don't do it right, because we can't be bothered to learn how".
It truly amazes me how some peoples worlds are black and white. I'd love to live it that world. First, I was NOT defending the practice I was stating that some companies in the real world whether right or wrong do not have the luxury or time to do things "right" by your definition. They have obligations (contractual or otherwise) to get it done and have it work under given time constraints.
Imagine how you would feel if your physician told you that he uses bloodletting instead of antibiotics, because antibiotics are complex, and bloodletting is "something that my nurses are already pretty much trained to do, because they know how to take samples for the lab"
Ok how about this if you want to talk about medicine, a medic on the battle field can stop the bleeding and sow up a wound with 10 stitches but that patient will live and he can move on to the next patient, or he can take his time, "do it right!" and use 50 stitches while the next patient bled to death.
I think the situations in which spending a little more time to develop your database code correctly puts people lives at risk are probably few and far between. I would be interested in hearing real-world situations where ensuring that your database code was correct resulted in someone's death. Or near death. Or papercuts.
In my world I often don't have time to do a perfect solution, I have to do the best I can under the time/contractual obligations that I am presented with and get something that works to the customer. Could it be done better...given more time absolutely....does work the way it was delivered...you betcha!
And when employers bother training their employees the quality of what can be delivered increases while the time to deliver decreases. It's a win-win. When you don't train employees the quality of work suffers and you spend a lot more time and money fixing things well after you're supposed to be done. It's not a recipe for happy customers.
Part of the problem with black and white arguments is they are rarely real world. They tend to exaggerate the opposite ends of the spectrum. The analogy is not one of blood letting vs antibiotics, it's one of antibiotics vs homeopathic solutions. Some would argue homeopathic is the better choice because of all the problem of over use of antibiotics causing drug resistance, homeopathic may be the "right" choice but it takes longer, and I need to get the infection under control ASAP!
Neither of those is the analogy. The analogy is about trained employees vs. untrained employees, happy customers vs. unhappy customers, a healthy revenue stream vs. bankruptcy.
My world exists somewhere in the middle and I've been doing this for a lot of years!!!
I don't understand this last statement. You seem to come out against training employees, but now you're "in the middle" somewhere. Just wondering what that means?
Nowhere did I say I was against training employees, quite the opposite. What I mean in the middle is I have to deliver product with the training/knowledge I have now. I may not have the luxury of time to learn/get training on what folks seem to be calling the "right way" for the project that I have to deliver now. Doesn't mean I won't get it. It just means I won't get it in time to use on yesterday's project. But I will use it on tommorw's project. To me there seems to a lot of black/white comments. "If you do that you're wrong...If you don't do that you're wrong" and for me it's not right or wrong it's in the middle. It was right yesterday given what I knew, just because tomorrow I know a better way doesn't make what I did yesterday wrong, just not as good. Does that make sense to anyone but me?
April 17, 2009 at 2:58 pm
bruce.trimpop (4/17/2009)
Lynn Pettis (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes whether you allow a developer who's lacking in experience to lower your expectations as an organization, or do you raise the skill levels of your inexperienced developers and teach them the best way to accomplish the tasks at hand to maintain high standards and meet high expectations?
Training is a luxury??? I'm sorry, it mandatory. If the company can't/won't provide it, then developers need to expend their own time and money in learning how to do their job better. It is part of their own professional development, keeping themselves relevant in the ever changing IT field.
I absolutely agree, but I did not say training was a luxury. I said ...well you can read what I said. 🙂
What I'm saying is that while the training is going on I still have product to deliver. So I deliver the best solution I can today which is when it's due.
Fortunately formal in-the-classroom training for large blocks of time is not the only type of training you can perform. On-the-job training is particularly important. When people are under pressure they take shortcuts that will cost you in the long run. Training allows people to write higher quality code in a shorter amount of time.
Tomorrow I find out about some new whiz bang feature in training... great I'll use that on the next project, but yesterday's project with the old "not right" solution, that works fine by the way, is out the door. If I have the luxury of some fee time maybe I'll be able to refactor it!
Or, depending on how your process works, you may have been told about this whiz bang new feature earlier during an architectural review. Or you may learn about this whiz bang new feature during a code review. Or you may learn about this whiz bang new feature from a senior mentor. And btw, set-based programming is not exactly a "whiz bang new feature".
The fact that the project "works fine by the way" is often a very narrow definition of the word "fine". What is more often than not meant is "it works fine by the way. On the system we tested it on here by the way. With the amount of data we tested it with by the way. Under the stress tests that we subjected it to by the way." Particularly when you're talking about cursors you can expect significant performance degradation under a variety of conditions. When a table triples in size, for instance. At least in the field I work in it's not a good idea to bet the farm on the amount of data in tables shrinking or remaining the same over time.
April 17, 2009 at 3:12 pm
Lynn Pettis (4/17/2009)
bruce.trimpop (4/17/2009)
Lynn Pettis (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes whether you allow a developer who's lacking in experience to lower your expectations as an organization, or do you raise the skill levels of your inexperienced developers and teach them the best way to accomplish the tasks at hand to maintain high standards and meet high expectations?
Training is a luxury??? I'm sorry, it mandatory. If the company can't/won't provide it, then developers need to expend their own time and money in learning how to do their job better. It is part of their own professional development, keeping themselves relevant in the ever changing IT field.
I absolutely agree, but I did not say training was a luxury. I said ...well you can read what I said. 🙂
What I'm saying is that while the training is going on I still have product to deliver. So I deliver the best solution I can today which is when it's due. Tomorrow I find out about some new whiz bang feature in training...great I'll use that on the next project, but yesterday's project with the old "not right" solution, that works fine by the way, is out the door. If I have the luxury of some fee time maybe I'll be able to refactor it!
Actually, you did say it was a luxury:
Ah, I see how it could be read that way. My bad. What I meant (and stated poorly), was that sometimes you don't have the time and luxury because you have a deadline that needs to be met. Training is never a bad thing, but a developer can't know everything (at least I can't, I'm always learning new things) when delivering a solution. They have to deliver the best solution they can at that time with the knowledge they have. If I learn a better way tomorrow great, good for me. That doesn't invalidate what I did yesterday.
April 17, 2009 at 3:17 pm
bruce.trimpop (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
GSquared (4/17/2009)
bruce.trimpop (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes.....
Exactly! 😉 Assuming, of course, your organization has the time and luxury to do so!
I can't imagine a single other professional field where people would actually defend the practice of "we don't do it right, because we can't be bothered to learn how".
It truly amazes me how some peoples worlds are black and white. I'd love to live it that world. First, I was NOT defending the practice I was stating that some companies in the real world whether right or wrong do not have the luxury or time to do things "right" by your definition. They have obligations (contractual or otherwise) to get it done and have it work under given time constraints.
Imagine how you would feel if your physician told you that he uses bloodletting instead of antibiotics, because antibiotics are complex, and bloodletting is "something that my nurses are already pretty much trained to do, because they know how to take samples for the lab"
Ok how about this if you want to talk about medicine, a medic on the battle field can stop the bleeding and sow up a wound with 10 stitches but that patient will live and he can move on to the next patient, or he can take his time, "do it right!" and use 50 stitches while the next patient bled to death.
I think the situations in which spending a little more time to develop your database code correctly puts people lives at risk are probably few and far between. I would be interested in hearing real-world situations where ensuring that your database code was correct resulted in someone's death. Or near death. Or papercuts.
In my world I often don't have time to do a perfect solution, I have to do the best I can under the time/contractual obligations that I am presented with and get something that works to the customer. Could it be done better...given more time absolutely....does work the way it was delivered...you betcha!
And when employers bother training their employees the quality of what can be delivered increases while the time to deliver decreases. It's a win-win. When you don't train employees the quality of work suffers and you spend a lot more time and money fixing things well after you're supposed to be done. It's not a recipe for happy customers.
Part of the problem with black and white arguments is they are rarely real world. They tend to exaggerate the opposite ends of the spectrum. The analogy is not one of blood letting vs antibiotics, it's one of antibiotics vs homeopathic solutions. Some would argue homeopathic is the better choice because of all the problem of over use of antibiotics causing drug resistance, homeopathic may be the "right" choice but it takes longer, and I need to get the infection under control ASAP!
Neither of those is the analogy. The analogy is about trained employees vs. untrained employees, happy customers vs. unhappy customers, a healthy revenue stream vs. bankruptcy.
My world exists somewhere in the middle and I've been doing this for a lot of years!!!
I don't understand this last statement. You seem to come out against training employees, but now you're "in the middle" somewhere. Just wondering what that means?
Nowhere did I say I was against training employees, quite the opposite. What I mean in the middle is I have to deliver product with the training/knowledge I have now. I may not have the luxury of time to learn/get training on what folks seem to be calling the "right way" for the project that I have to deliver now.
Everyone has the same constraints, it's sort of implied that you can't deliver more than you have the knowledge and capability to deliver. When you train your employees you increase their knowledge, capability, and efficiency. I'm not going to say if you don't train your employees you're wrong. I will say that it will cost you a lot more in the long run.
I won't even say that using cursors is "wrong" -- it's a lifestyle choice AFAIC. But I will say that using cursors will cost you in the long run as well.
Here's the thing, what this whole conversation and the article boils down to is "Best Practices". Here is "Best Practices" in three easy steps:
1. Some guy 1,000 years ago ate a red spotted mushroom and died.
2. Another guy wrote this fact down.
3. Now you don't have to eat the red spotted mushroom just to find out whether or not it will kill you.
In terms of database development, there are millions of people who tried to do things a certain way. When those methods failed, they wrote them up and shared them with the world. When those methods succeeded, they wrote them up and shared them with the world. Still others took comparable successful methods and tested them against one another to determine which were the "best" of the successful methods. In other words, we don't necessarily have to make the same mistakes as our predecessors because they already made those mistakes, and they told us about them! In fact, we have the luxury of picking and choosing the best documented methods for a given set of criteria and circumstances. These methods have been vetted by millions of people over the course of decades now.
Doesn't mean I won't get it. It just means I won't get it in time to use on yesterday's project. But I will use it on tommorw's project. To me there seems to a lot of black/white comments. "If you do that you're wrong...If you don't do that you're wrong" and for me it's not right or wrong it's in the middle. It was right yesterday given what I knew, just because tomorrow I know a better way doesn't make what I did yesterday wrong, just not as good. Does that make sense to anyone but me?
Just because something appeared to succeed under the very specific set of circumstances under which it was tested today doesn't mean it will always work well, or even work at all. That is to say just because the red spotted mushroom you ate today didn't have enough toxins to finish you off doesn't mean giving one to your customer was the right thing to do.
Viewing 15 posts - 256 through 270 (of 380 total)
You must be logged in to reply to this topic. Login to reply