February 12, 2011 at 10:32 am
Tom.Thomson (2/12/2011)
Craig Farrell (2/11/2011)
Anyone here mind if I cut loose on him? I truly believe he'll be tasty. I wanna eat him.My view is that if you're certain he's a troll, and not some poor benighted kid totalling lacking in confidence and self-respect, you can go ahead and cut loose; but you should not do that if you are noty certain.
Just my 2 cents... If he's a troll or just someone who cannot be made to understand (ie: learn) and becomes vicious in his/her arguments, then just move on because "A man forced against his will is of the same opinion still". Same holds true for "ring knockers" and the like. I understand that it's not always an easy joy to let someone "get away" with saying some things but there are good people that need and will take help and they are more important to me.
The other thing to carefully consider is... if a potential employer saw your retort and only your retort, what would they think?
Unless their arguments will cause someone to create code that could lose or damage data, stop addressing the person directly.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 12, 2011 at 10:41 am
Tom.Thomson (2/12/2011)
Koen Verbeeck (2/12/2011)
The Dixie Flatline (2/11/2011)
QA is where some developers send their code to see if it works correctly or not. Often they do this without verifying that it works in their development environment. After all, they are developers, not testers.... right?A developer should of course test if his code does what it is supposed to do and if it compiles et cetera, but in my opinion, extensive testing should not be done by the person who wrote the code, but by someone else. A developer might think his code is perfect, so why bother testing, right?
Quite a frightening idea!
You seem to be saying that developers should do minimal unit testing and no more. The idea horrifies me. When developers are not required to show that their code really does its job (which is a good deal more than compile correctly and work in the development environment) they tend to lose the sense that it must work, QA raising issues that don't turn up in the dev environment is seen as a pain , a nuisance, and product quality goes to pot.
Developers should, in my view, do exhaustive testing of their code: unit testing, system testing, and stress testing (often that means that developers have to work together to put together the tests; fine, that happens because they had to work together to build the system so why should it be a problem to work together on testing too?). That includes performance measurement, checking what happens when someone pulls the plug on part of the equipment, feeding in garbage at the UI to make sure its rejected with suitable warnings, measuring scalability, and checking system limits. For the purposes of this testing DBAs have to be treated as part of the development test team. Adequate equipment has to be provided to allow proper tests to be carried out. Full test reports of unit tests, system tests, resilience tests, invalid input tests, and stress tests should be generated and given to QA along with the software, installation instructions, user documentation, and configuration guide.
QA should be a verification/validation stage after the product has been signed off by development as fit for release - and if QA decide it isn't fit that should be regarded as a major development failure. QA should grill development about system limits, about performace expectations, and everything else, document the answers, and check that everything fits, not just check that code delivers the functional specifications (unless you include performace, resilience, scalability, system limits, and everything else in the functional specification).
I've worked in places where developers did proper testing, and in places where they didn't; I know which ones produced better code and maintained better morale amongst developers, and it wasn't the one that deprived them of the opportunity to test their own product properly.
On your "After all" point: I guess you =have known some pretty awful developers; yes, it's a common attiotude amongst junior developers, and it's hard work to wean them from this silly attitude, and convince them that the sun doesn't shine from their lower backs. Senior developers that don't bother to test because they think their code must be perfect because they wrote it are generally a waste of space, and probably should not be employed (probably should never have been placed in a senior position); there is the odd one here and there who has such bright ideas that despite his attitude to testing he is a usefulk member of the team, but they are very few and very far between.
edit: spelling
Ok... it's official. I'm officially jealous of anyone who has the opportunity to work with you on just about any project, Tom.
Like you, I also believe that developers should do extensive testing of their own code and, perhaps, even help QA with test setup code (what the hell... they've already done it!). We did such a thing at one of my previous companies... it usually took twice as long to develop the code but it also dropped rework for QA-failed code from "DevelopmentTime * 8" to near zero. We saved hundreds of developer and tester hours per month and the amount of time to actually deliver final product to production fell through the floor. Post production failures also dropped to near zero.
THAT was both on the GUI and Database sides of the house! π
--Jeff Moden
Change is inevitable... Change for the better is not.
February 12, 2011 at 11:33 am
Jeff Moden (2/12/2011)
Ok... it's official. I'm officially jealous of anyone who has the opportunity to work with you on just about any project, Tom.
I was describing they way things should be, which isn't always the way they are. I've been in places where it was done that way, but also in places where it wasn't. If I'm in charge it's either right or (when there isn't enough money available) right except for inadequate supply of test equipment, but when I've not been in charge as well as some good times I've also seen software ripped from the hands of development before they were satisfied with even the unit tests.
Another of my preferences is that developers should get involved in customer support - it leads to a much better understanding of usability issues (what the developer thought was rather pointless he now knows is crucial) and of the seriousness of bugs (that small problem in an obscure corner of the product is going to put the customer out of business if it isn't fixed or at least alleviated soon), and when developers are congratulated by a customer on having helped to produce a superb product it does marvels for morale (and hence for productivity). That's also been done right in some places, and just not happened in others.
Tom
February 12, 2011 at 11:36 am
Jeff Moden (2/12/2011)
Just my 2 cents... If he's a troll or just someone who cannot be made to understand (ie: learn) and becomes vicious in his/her arguments, then just move on because "A man forced against his will is of the same opinion still". Same holds true for "ring knockers" and the like. I understand that it's not always an easy joy to let someone "get away" with saying some things but there are good people that need and will take help and they are more important to me.The other thing to carefully consider is... if a potential employer saw your retort and only your retort, what would they think?
I hadn't thought of that one - you are absolutely right, it has to be considered, and should be a very important consideration for most people.
Tom
February 12, 2011 at 11:43 am
Tom.Thomson (2/12/2011)
Koen Verbeeck (2/12/2011)
The Dixie Flatline (2/11/2011)
QA is where some developers send their code to see if it works correctly or not. Often they do this without verifying that it works in their development environment. After all, they are developers, not testers.... right?A developer should of course test if his code does what it is supposed to do and if it compiles et cetera, but in my opinion, extensive testing should not be done by the person who wrote the code, but by someone else. A developer might think his code is perfect, so why bother testing, right?
Quite a frightening idea!
You seem to be saying that developers should do minimal unit testing and no more. The idea horrifies me. When developers are not required to show that their code really does its job (which is a good deal more than compile correctly and work in the development environment) they tend to lose the sense that it must work, QA raising issues that don't turn up in the dev environment is seen as a pain , a nuisance, and product quality goes to pot.
Developers should, in my view, do exhaustive testing of their code: unit testing, system testing, and stress testing (often that means that developers have to work together to put together the tests; fine, that happens because they had to work together to build the system so why should it be a problem to work together on testing too?). That includes performance measurement, checking what happens when someone pulls the plug on part of the equipment, feeding in garbage at the UI to make sure its rejected with suitable warnings, measuring scalability, and checking system limits. For the purposes of this testing DBAs have to be treated as part of the development test team. Adequate equipment has to be provided to allow proper tests to be carried out. Full test reports of unit tests, system tests, resilience tests, invalid input tests, and stress tests should be generated and given to QA along with the software, installation instructions, user documentation, and configuration guide.
QA should be a verification/validation stage after the product has been signed off by development as fit for release - and if QA decide it isn't fit that should be regarded as a major development failure. QA should grill development about system limits, about performace expectations, and everything else, document the answers, and check that everything fits, not just check that code delivers the functional specifications (unless you include performace, resilience, scalability, system limits, and everything else in the functional specification).
I've worked in places where developers did proper testing, and in places where they didn't; I know which ones produced better code and maintained better morale amongst developers, and it wasn't the one that deprived them of the opportunity to test their own product properly.
On your "After all" point: I guess you =have known some pretty awful developers; yes, it's a common attiotude amongst junior developers, and it's hard work to wean them from this silly attitude, and convince them that the sun doesn't shine from their lower backs. Senior developers that don't bother to test because they think their code must be perfect because they wrote it are generally a waste of space, and probably should not be employed (probably should never have been placed in a senior position); there is the odd one here and there who has such bright ideas that despite his attitude to testing he is a usefulk member of the team, but they are very few and very far between.
edit: spelling
I don't think problems found by QA are necessarily major development failures. We all have blind spots, especially when it comes to something we've created. I don't mean that a programmer will think his code is good, I mean that a programmer will not think to test certain aspects because it wasn't part of their intent. Good QA should approach a program or system both from the full performance requirements you list, but also from the point of view of an end user and that's something any developer is going to have a very hard time doing.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
Itβs unpleasantly like being drunk.
Whatβs so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
February 12, 2011 at 12:32 pm
re the nadabadan thread - I think you are all overthinking this, if it looks like a troll, smells like a troll and acts like a troll - its a troll.
So ignore him.
Personally I am sad this thread got overwhelmed in this way, I actually posted a half decent answer to a coding question, which like hardly ever happens :-), and now its lost forever.
And why do people post a reply thats almost a verbatim copy of a previous post? Being proved wrong I can just about take (with embarrasement) but ignored, that hurts! π
---------------------------------------------------------------------
February 12, 2011 at 12:38 pm
Stefan Krzywicki (2/12/2011)
I don't think problems found by QA are necessarily major development failures. We all have blind spots, especially when it comes to something we've created. I don't mean that a programmer will think his code is good, I mean that a programmer will not think to test certain aspects because it wasn't part of their intent. Good QA should approach a program or system both from the full performance requirements you list, but also from the point of view of an end user and that's something any developer is going to have a very hard time doing.
Well, maybe "major" was the wrong word. What I meant was that (in the ideal development and QA and Release world) each development problem/bug detected in QA should cause development to undertake a careful review to see if there is some kind or procedural fault (whether in develpment's design, or its coding, or its testing) whose fixing would prevent any similar problems in future; and if there isn't such a problem, is there a training issue (get developers to understand some algrithm and its limitations better, or get them to understand some aspect of the end-user viewpoint better, or get them to understand testing coverage and the limits of particluar testing modes better, or whatever) or an infrastructure issue (eg is development unable to test everything properly because they don't have access to the necessary equipment, and if so is it commercially viable to acquire the required access). I didn't intend "major" to imply a scapegoat -finding excercise, or a blame attribution excercise, or any of the other stupidities that so many managers indulge in, since clearly the developer team are not able to produce perfect results every time - it is after all a group of human beings. Some of the time the conclusion of such a review is that this is one of those problems that arise from constraining the development process to be finite and affordable (but don't let the accountants anywhere near that decision :angry: - they never understand that losing 1,000,000 next year is a bigger problem than spending 10 now - let the business managers decide [if the business managers are accountants, start polishing your resume :-D]). Similarly any problem at a customer site should cause reviews in development, QA, and sales (if the customer has been sold features that are not supported, or has been sold the future with early dates, or has had the capabilities of the product exaggerated to him, that's a sales issue).
Tom
February 12, 2011 at 12:48 pm
Jeff Moden (2/12/2011)
Tom.Thomson (2/12/2011)
Craig Farrell (2/11/2011)
Anyone here mind if I cut loose on him? I truly believe he'll be tasty. I wanna eat him.My view is that if you're certain he's a troll, and not some poor benighted kid totalling lacking in confidence and self-respect, you can go ahead and cut loose; but you should not do that if you are noty certain.
Just my 2 cents... If he's a troll or just someone who cannot be made to understand (ie: learn) and becomes vicious in his/her arguments, then just move on because "A man forced against his will is of the same opinion still". Same holds true for "ring knockers" and the like. I understand that it's not always an easy joy to let someone "get away" with saying some things but there are good people that need and will take help and they are more important to me.
The other thing to carefully consider is... if a potential employer saw your retort and only your retort, what would they think?
Unless their arguments will cause someone to create code that could lose or damage data, stop addressing the person directly.
Oh, I realize your argument, Jeff, and it is what I originally did. However, your statement can go both ways. Do you simply ignore a problem or do you address it?
I just wanted to make sure noone here was still trying to salvage the situation with him in this case.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
February 12, 2011 at 12:57 pm
george sibbald (2/12/2011)
And why do people post a reply thats almost a verbatim copy of a previous post? Being proved wrong I can just about take (with embarrasement) but ignored, that hurts! π
I imagine mglumpa did that because he read the original question and then read no further, just replied instantly; forgive him, he's a very new newby (he has only posted 5 times, including anything he posted since then).
Tom
February 12, 2011 at 1:20 pm
george sibbald (2/12/2011)
And why do people post a reply thats almost a verbatim copy of a previous post? Being proved wrong I can just about take (with embarrasement) but ignored, that hurts! π
Sometimes (especially on short threads) I suspect that the people are trying to get credit (forum ranking) without working. I soooo often see a 3-5 post thread where someone has replied after me and paraphrased what I said.
Cynical? Yup.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 12, 2011 at 1:51 pm
GilaMonster (2/12/2011)
george sibbald (2/12/2011)
And why do people post a reply thats almost a verbatim copy of a previous post? Being proved wrong I can just about take (with embarrasement) but ignored, that hurts! πSometimes (especially on short threads) I suspect that the people are trying to get credit (forum ranking) without working. I soooo often see a 3-5 post thread where someone has replied after me and paraphrased what I said.
Cynical? Yup.
I personally always try to look at the timestamps when that happens. I quite often will go through the recent posts and open up the 20 or so I'm interested in and then get around to reading through them. I have to assume that usually either I or they just cross the lines when that happens.
Though, if it's a 2 hours difference... I certainly can't argue. :hehe:
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
February 12, 2011 at 1:55 pm
Craig Farrell (2/12/2011)
I personally always try to look at the timestamps when that happens. I quite often will go through the recent posts and open up the 20 or so I'm interested in and then get around to reading through them. I have to assume that usually either I or they just cross the lines when that happens.
I do the same, mostly so that by the time I've opened all the ones that look interesting the first couple have fully loaded
Though, if it's a 2 hours difference... I certainly can't argue. :hehe:
It's the hour or more difference that I was thinking of, and the second post says exactly what I said, no more, no less, just in different words.. I could locate a couple repeat offenders, but it's not worth the energy right now.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 12, 2011 at 3:45 pm
Tom.Thomson (2/12/2011)
george sibbald (2/12/2011)
And why do people post a reply thats almost a verbatim copy of a previous post? Being proved wrong I can just about take (with embarrasement) but ignored, that hurts! πI imagine mglumpa did that because he read the original question and then read no further, just replied instantly; forgive him, he's a very new newby (he has only posted 5 times, including anything he posted since then).
yes I saw that and decided in that instance it could just be newness to SSC.
I just needed to vent as it seemed to be happening a lot to me recently!
I have probably done it myself without realising it in the distant past, most likely to Gail π
---------------------------------------------------------------------
February 12, 2011 at 3:50 pm
GilaMonster (2/12/2011)[hrI could locate a couple repeat offenders, but it's not worth the energy right now.
I can think of one who did very well out of it............
---------------------------------------------------------------------
February 12, 2011 at 3:54 pm
george sibbald (2/12/2011)
I have probably done it myself without realising it in the distant past, most likely to Gail π
Nah, you and I tend to post within seconds of each other with similar answers.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 15 posts - 23,941 through 23,955 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply