Psychic Code

  • Swedish tard 2012-11-07 08:35
    Ouch.
    I've seen som rancid scripts, but that really takes the cake. Rather belongs in IOCCC or similar.
  • Warren 2012-11-07 08:40
    They need to test that no-one's checked this bit of code back in. So now they need a test script that runs svn....
  • mz001 2012-11-07 08:44
    Sounds kinda familiar.
    I recently inherited an application where the previous guy screwed up so badly that the only solution is to keep the basic idea and to a complete rewrite. On the bright side, the guy's now working at a younger competitor and will probably have run them into the ground in less than a year.
  • Kushan 2012-11-07 08:48
    Simple rule with regex, if it's more than the old terminal width of 80 characters, you're doing it wrong. Hell, even that's pushing it.
  • Yaos 2012-11-07 08:55
    If your code does not look like your rolled your face over the keyboard you're not doing regular expressions right.
  • dkackman 2012-11-07 08:56
    "Like snakes and mongooses , QA and developers are natural enemies."

    Best quote ever. Putting on my whiteboard
  • @Deprecated 2012-11-07 08:57
    Kushan:
    Simple rule with regex, if it's more than the old terminal width of 80 characters, you're doing it wrong. Hell, even that's pushing it.

    Thank FSM, I thought you were going to roll out that tired old "Now you have two problems" bit.
  • Remy Porter 2012-11-07 09:00
    A developer wants to make a joke about regexes, so they trot out the "two problems" bit. Now they have two jokes.

    ... I'm not sure that worked.
  • El Dorko 2012-11-07 09:01
    What I've been saying all the time to my team: you can write all the regex you want to save some typing or characters or whatever, but you'll end up writing way more documentation to go with that. Here, there is no undocumented regex (yes they still use it for some tasks and that's fine by me). And I check that the documentation makes sense. And I snap at the culprit when it doesn't.
  • NameNotFoundException 2012-11-07 09:02
    Why, oh why did they let the other guy go? My job security dreams just vanished...
  • Rhywden 2012-11-07 09:04
    http://ars.userfriendly.org/cartoons/?id=20070628&mode=classic
  • Bongo 2012-11-07 09:10
    No unicorns :(
  • gar37bic 2012-11-07 09:36
    The idea of a script reading itself reminds me of Mortran, a 'structured FORTRAN preprocessor', developed (IIRC) at U of Waterloo. The preprocessor was a quite simple macro processor. The key to the preprocessor was an initial macro, which expanded to become the de facto processor, which processed the macros that implemented the language structures. (All of this IIRC). In essence, that original 'rule' (macro) defined the direction of construction of the language.

    This bootstrap process gave me to think about creation and evolution, in the following manner. It's one thing to create something out of whole cloth - a butterfly, for instance. But it's an entirely different and much more interesting thing to create something by merely defining a set of rules by which an entire universe constructs itself, that evolves resulting in, of course, (and among other 'things'), us. :) It's sort of like aiming a gun by growing a tree to support the barrel. So since then I have never seen any essential conflict between this sort of original 'creation' (by whatever means) and 'evolution'.

    Of course, it is also useful to add one element from systems science - the principal that a controller of a system must have more complexity than the system, else it is not a controller. This means that no member of the system can determine whether there is a controller or not. So the whole creation/evolution argument is undecidable. In any case, it's fun to think that a programming language is a metaphor for evolution!
  • Ron 2012-11-07 09:57
    Note that the comment says "I forget what this does", not "I forgot what this does".

    Sounds more like a declaration of intent: "I _will_ forget what this does". I can understand why. I wouldn't want to remember this, either.



  • AGray 2012-11-07 10:00
    So, a true story on this note, but heavily sanitized to protect the innocent.

    I recently moved into a developer postion, from automated QA. The problem? On my team, I'm the only person with that skillset left.

    Enter a series of Ranorex/C# programs written by my predecessors. Some of these scripts are bad in the simplest sense - they sometimes work in theory (often not), but rarely work in practice. My last week since originally being tasked with maintaining these functional tests has been mostly rewriting, since the previous contributors weren't exactly clear on things like a 'Common' library being...well, common. Or, that whitespace does wonders to make code legible. Or the difference between bitwise OR and short-circuit OR in C#.

    Long story short...I feel this possibly fictionalized programmer's pain. I'm just glad my pain is not the equal of that.
  • atk 2012-11-07 10:02
    Like snakes and mongooses , QA and developers are natural enemies.


    I've heard that bu11$#!t before, and it's still BS - even with the possibility that it's here only for humor. You'd expect to see attitudes like this from immature, fresh-out-of-school programmers. But sadly, we see it from many experienced developers, management, and even college professors. It's attitudes like this that create unnecessary tension between teams whose joint purpose is to deliver a product to market that people will buy.

    All quality and all bugs come from development. Development is fully responsible for the quality (or lack thereof) in a product. Nobody else writes the code. Nobody else creates the bugs. (For the pedants, product management is responsible for requesting a product that customers will want, but they're still not the ones that do or do not build in quality.)

    If the product is lacking in quality, either customers won't buy it, or they'll demand support. If they don't buy it, the company doesn't make money and nobody gets paid. If customers demand support, that costs the company money. If it costs the company too much money, and support is equally or more expensive than profits, the company loses money and nobody gets paid. And the second order issues like low quality risking the company's reputation (other potential customers may not buy the product of a company with a bad reputation) and customer good will (lack thereof leads to loss of future sales and sometimes customers demanding their money back or expensive freebees).

    QA exists to identify the level of quality in a product before it ships so that a decision can be made as to whether it will make the company money or cost the company money.

    So that they company can make money.

    Whether developers, professors, or anyone else realize it or not, this is the same goal as development has - to make the company money and get paid.



    BTW, I'm a developer.
  • Bubbles 2012-11-07 10:03
    What's with the dev/QA hate? I love our QA team, they're very good and they help us devs a ton. And we go out for beers together too.
  • Chris 2012-11-07 10:08
    Bridget is obviously not a Real(tm) developer.

    Any developer worth their salt wouldn't spend more than about 30 minutes tracing through a pile of unused crap before declaring that it is indeed crap.

    This is always quickly followed by the developer starting over with the given code. Usually leading to another pile of unused crap that needs to be replaced.
  • Foo 2012-11-07 10:12
    Remy Porter:
    A developer wants to make a joke about regexes, so they trot out the "two problems" bit. Now they have two jokes.

    ... I'm not sure that worked.

    how about "a dev wants to make a joke about regexes, so they trot out the "two problems" bit. Now they have two memes.
  • Foo 2012-11-07 10:15
    This kinda stuff probably comes from an automated script which tries to update itself. If you've got a few machines in a cupboard somewhere churning a large regression set, you want them to auto-update... and I can't say I've ever seen a neat solution to auto-update.
    This sounds like it attempted to get the latest version of itself and everything it needed from source control, which is a great concept, but sucky implementation.
  • dkallen 2012-11-07 10:16
    Remy Porter:
    A developer wants to make a joke about regexes, so they trot out the "two problems" bit. Now they have two jokes.

    ... I'm not sure that worked.


    A commenter wants to make a joke out of a comment, so he trots out the quote/comment/joke meme. Now he has two comments, and no jokes.
  • dkallen 2012-11-07 10:26
    atk:
    Like snakes and mongooses , QA and developers are natural enemies.


    You'd expect to see attitudes like this from immature, fresh-out-of-work trolls.

    If the product is lacking in quality ship it [s]o that [the] company can make money before laying off the developers.

    ...this is the same goal as development has - to take the company's money and get laid.


    BTW, I'm a troll


    There, FTFY.
  • RichP 2012-11-07 10:27
    Shouldn't the plural of "mongoose" be "mongeese"?
  • DCRoss 2012-11-07 10:34
    RichP:
    Shouldn't the plural of "mongoose" be "mongeese"?


    It's mongooses. Or mongui, if you prefer.
  • Anon') or 1=1 2012-11-07 10:35
    RichP:
    Shouldn't the plural of "mongoose" be "mongeese"?


    You didn't read the HTML comments, did you?
  • JC 2012-11-07 10:36
    Devs can hate QA as much as they like. Trust me, you'll hate it much more when you dont have a QA team and you have to DIY.
  • Remy Porter 2012-11-07 10:38
    I'm in a situation where the BA writes the test cases (poorly, usually), and then the developer executes the test cases (also poorly). But the customers refuse to pay for QA.
  • neminem 2012-11-07 10:49
    DCRoss:
    RichP:
    Shouldn't the plural of "mongoose" be "mongeese"?


    It's mongooses. Or mongui, if you prefer.


    No, a mongui would be a (slightly racially insensitive, if you track down the etymology) derogatory term for a really terrible user interface.

    I like "mongeese". Totally incorrect, but I still like it.
  • Nemo 2012-11-07 10:58
    Bah! Developers and QA get along great! The real fight is between the developers and the admins.
  • justsomedudette 2012-11-07 11:03
    neminem:
    DCRoss:
    RichP:
    Shouldn't the plural of "mongoose" be "mongeese"?


    It's mongooses. Or mongui, if you prefer.


    No, a mongui would be a (slightly racially insensitive, if you track down the etymology) derogatory term for a really terrible user interface.

    I like "mongeese". Totally incorrect, but I still like it.
    I like mongeeses which is even worse, but I still like it.
  • Neil 2012-11-07 11:14
    Anon') or 1=1:
    RichP:
    Shouldn't the plural of "mongoose" be "mongeese"?
    You didn't read the HTML comments, did you?
    I just wanted to note that the space before the comma is a dead giveaway.

    CAPTCHA: sagaciter - someone who cites sagas.
  • callcopse 2012-11-07 11:17
    Jeez, me and the QAs, and the admins, and the PMs are all down.

    It's the SALES folk who are sworn enemies at DNA level. Get it right.
  • Ralph 2012-11-07 11:21
    atk:
    If the product is lacking in quality, ... customers won't buy it
    OK, I know I'm evaluating one half of an "or", but clearly this has a vanishingly small probability and therefore should be optimized out. Consider:

    Microsoft
    Oracle
    Adobe
    SAP
    HP
    ...
    Members of Congress
    ...
  • Jack 2012-11-07 11:29
    Remy Porter:
    I'm in a situation where the BA writes the test cases (poorly, usually), and then the developer executes the test cases (also poorly).
    Test cases? I envy your luxurious life in a mature organization. Here's how it works here:

    1. Internal customer describes what they want.

    2. Development builds whatever they feel like making, spending countless hours obsessing over exactly how round the corners should be, but giving no thought to data structures.

    3. Customer is responsible for testing; documents 100 bugs.

    4. Developers give up and go on to another project.

    5. Rinse and repeat.

    6. ???

    7. Profit!

    We just hired our first QA guy. And this is in an IT organization with over 300 employees.

    P.S. We have never made it to step 7, perhaps because of the endless loop in 5.
  • Ozz 2012-11-07 11:35
    I thought everyone knew that the plural of "mongoose" is "polygoose".
  • chubertdev 2012-11-07 11:50
    Nice Gir reference in the HTML comments.

    "I saw a squirrel!"
  • Sebastian Buchanan 2012-11-07 12:14
    it would be cooler if the regex created an svn client
  • chubertdev 2012-11-07 12:15
    Sebastian Buchanan:
    it would be cooler if the regex created an svn client


    And that is how SourceSafe was created.
  • SunGoose 2012-11-07 12:34
    Ozz:
    I thought everyone knew that the plural of "mongoose" is "polygoose".


    Good one.

    Another possible sequence is: "MonGoose", "TueGoose", "WedGoose"...
  • someone 2012-11-07 12:51
    That actually sounds like a good way to check for typos/errors. Like the static type checking you had in a compiled language.

    The TWTF is that they deleted the function
  • Alin 2012-11-07 12:55
    Yaos:
    If your code does not look like your rolled your face over the keyboard you're not doing regular expressions right.


    Made my day :)
  • Herp 2012-11-07 13:15
    Chris:
    Bridget is obviously not a Real(tm) developer.

    Any developer worth their salt wouldn't spend more than about 30 minutes tracing through a pile of unused crap before declaring that it is indeed crap.

    This is always quickly followed by the developer starting over with the given code. Usually leading to another pile of unused crap that needs to be replaced.


    Would politely disagree. Yes, some bad code is so bad that it is not salvageable. In many cases, though, the cost of refactoring is less than the cost of starting over from scratch.
  • Nagesh 2012-11-07 13:20
    mz001:
    Sounds kinda familiar.
    I recently inherited an application where the previous guy screwed up so badly that the only solution is to keep the basic idea and to a complete rewrite. On the bright side, the guy's now working at a younger competitor and will probably have run them into the ground in less than a year.


    IT CANNOT BRING OPERATION TO STANDSTILL. THAT IS TRUTH OF MATTER.
  • Daniel 2012-11-07 13:33
    Oh my. I'm laughing and crying at the same time. Wouldn't be funny or tragic if it weren't so terrifyingly accurate.
  • Hasse 2012-11-07 13:37
    Any person that want to call himself a developer/programmer should work 2 years:

    1: as a system administrator
    2: in QA
    3: as a maintenance programmer

    Then they learn how badly maintainable programs could be.
    How horrible functionality a program can have
    How bad code looks like
  • eVil 2012-11-07 14:15
    SunGoose:
    Ozz:
    I thought everyone knew that the plural of "mongoose" is "polygoose".


    Good one.

    Another possible sequence is: "MonGoose", "TueGoose", "WedGoose"...


    WednesGoose surely?
  • lesle 2012-11-07 14:26
    Collective Nouns for Mongoose

    A business of mongoose (most commonly cited)
    A band of mongoose
    A pack of mongoose
    A mongaggle of mongoose (probably made up, but nice!)
    ---
    A mongoose is a type of weasel.
  • Zylon 2012-11-07 14:30
    Bongo:
    No unicorns :(

    But we got the usual slipshod editing, so there's that.

    ...she needed to know out what it was actually trying to do...

    Yes, let us all sally forth and know out the problem!
  • da Doctah 2012-11-07 14:33
    Bubbles:
    What's with the dev/QA hate? I love our QA team, they're very good and they help us devs a ton. And we go out for beers together too.


    IWPTA as "go out for bears together".

    (Now, where's this Eskimo woman you want me to wrestle?)
  • Anonymous bastard 2012-11-07 14:42
    Nemo:
    Bah! Developers and QA get along great! The real fight is between the developers and the admins.

    Specially the windows admins...
  • bgodot 2012-11-07 14:50
    Like Nazgûl and Hobbits.
  • JoeT 2012-11-07 15:32
    The trouble is, there are a *lot* of QA people who feel their only job is to fill their quota of bugs reported.

    Never mind that the bug is silly. Never mind that they provide no way to reproduce. Never mind that the bug doesn't actually exist.

    Three (real but simplified/censored) examples:

    Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."

    Bug 2: "When I run [well defined testcase] in my environment it crashes"

    Bug 3: "When all of the servers are down, the testcases fail."

    Sadly, we did fix bug 1. We never figured out bug 2; we never could figure out what "my environment" was. Not for want of asking; it clearly did crash, just never in front of anyone but the tester. Bug 3 eventually lead to the firing of the sysadmin staff; I don't care what you think of me, but I refuse to try to make my software run properly on a machine that is powered down.

    And QA should at least be able to run the debugging step of "is your computer plugged in?".
  • C-Derb 2012-11-07 15:44
    Hasse:
    Any person that want to call himself a developer/programmer should work 2 years:

    1: as a system administrator
    2: in QA
    3: as a maintenance programmer
    You can't simply blame developers for not understanding the QA/Sys Admin/Maint Programmer point of view. This same logic needs to be applied to all 4 groups you have mentioned.

    Take the app I'm working on for example. When our QA person comes up with test plans that rely on changeable data in our DEV environment, why should I get push back when I point out that the data will be different in the TEST environment and those tests probably won't pass? (Ie. I do a search for "xyz" and get 45 results back in DEV. Not gonna happen in TEST, so don't rely on the number 45. "Why?" "Because the data in TEST is not the same as the data in DEV." "Why?" "Because...ah forget it, your test looks great." )
  • Tom 2012-11-07 15:56
    atk:
    Like snakes and mongooses , QA and developers are natural enemies.


    I've heard that bu11$#!t before, and it's still BS - even with the possibility that it's here only for humor.

    [rant snipped for brevity]

    BTW, I'm a developer.


    And an awfully high-strung one, it seems. Try decaf.

    Captcha: persto. "Persto! My self-aware regex-based script wroks!"
  • C-Derb 2012-11-07 15:58
    JoeT:

    Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
    This is a perfect example of the seeds of animosity between QA and developer.

    I have worked with QA people who find trivial issues like this that were never defined in the requirements, but they log them as bugs because it violates their own personal preferences of how they believe the application should work.

    Just this week in our planning meeting for our upcoming release, the product manager has added a task to have the application retain the form values after postback. I smiled and shook my head. They asked what I was smiling about. I told them, "The application was working exactly that way initially, but QA-person [since retired] demanded that the form be cleared on postback. I protested and lost. Should be an easy fix."
  • cdosrun 2012-11-07 15:58
    JoeT:
    The trouble is, there are a *lot* of QA people who feel their only job is to fill their quota of bugs reported.

    Never mind that the bug is silly. Never mind that they provide no way to reproduce. Never mind that the bug doesn't actually exist.


    Want another?

    Defect: Product name "Compoundword" should be "Compound word".

    Really? This is an established product, and no one has ever mentioned that we are changing the name... are you sure? If the requirements change, why didn't they tell us? Fine, whatever

    The next day-

    Defect: Product name "Compound word" should be "Compound Word".

  • Tom 2012-11-07 16:03
    [quote user="RichP"]Shouldn't the plural of "mongoose" be "mongeese"?[/quote

    And a baby mongoose would then be a "mongosling?"
  • Quincy 2012-11-07 16:12
    C-Derb:
    JoeT:

    Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
    I have worked with QA people who find trivial issues like this that were never defined in the requirements
    Maybe there's a hint there.

    Close the bug report as "invalid bug submission: missing requirement ID"
  • C-Derb 2012-11-07 16:38
    Quincy:
    C-Derb:
    JoeT:

    Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
    I have worked with QA people who find trivial issues like this that were never defined in the requirements
    Maybe there's a hint there.

    Close the bug report as "invalid bug submission: missing requirement ID"
    You've got a point, as long as you are working somewhere that wants to use a software system to actually log bugs. Right now, the bugs get logged one of three ways: 1) the QA person interrupting my work with "Hey, this is a bug...", or 2)an IM interrupting my work with "Hey, this is a bug..." or 3)an email with "Hey, this is a bug..." immediately followed by 1) or 2) asking "did you get my email?"

    Either way though, once the conversation moves to "this is a bug"/"No it isn't", the bad blood starts to develop. Bottom line: QA is there to test that software meets requirements. When QA tries to define requirements, I get annoyed.
  • Vlad Patryshev 2012-11-07 16:39
    Uroboros. "The script apparently reads itself to find out what it’s doing."

    Love it.
  • C-Derb 2012-11-07 16:45
    cdosrun:

    Defect: Product name "Compoundword" should be "Compound word".

    Really? This is an established product, and no one has ever mentioned that we are changing the name... are you sure? If the requirements change, why didn't they tell us? Fine, whatever

    The next day-

    Defect: Product name "Compound word" should be "Compound Word".

    Exactly.
  • Hasse 2012-11-07 16:48
    Sortof agree with you, but I'm convinced you QA person will never make it to Developer as he sees not to understand basic Computer Science
  • realmerlyn 2012-11-07 16:57
    gar37bic:

    This bootstrap process gave me to think about creation and evolution, in the following manner. It's one thing to create something out of whole cloth - a butterfly, for instance. But it's an entirely different and much more interesting thing to create something by merely defining a set of rules by which an entire universe constructs itself, that evolves resulting in, of course, (and among other 'things'), us. :) It's sort of like aiming a gun by growing a tree to support the barrel. So since then I have never seen any essential conflict between this sort of original 'creation' (by whatever means) and 'evolution'.


    Step 1: ponder that
    Step 2: ???
    Step 3: LISP!
  • Simon 2012-11-07 17:40
    Ralph:
    atk:
    If the product is lacking in quality, ... customers won't buy it
    OK, I know I'm evaluating one half of an "or", but clearly this has a vanishingly small probability and therefore should be optimized out. Consider:

    Microsoft
    Oracle
    Adobe
    SAP
    HP
    ...
    Members of Congress
    ...


    Why are the latter on the list? Traditionally, politicians are of excellent quality and value for money - for those who actually buy them.
  • Silverhill 2012-11-07 17:56
    Herp:
    Yes, some bad code is so bad that it is not salvageable.
    Or, as Sam Goldwyn (of MGM) put it, "You can't polish a turd."


    JoeT:
    Never mind that [QA people] provide no way to reproduce.
    Would that that were so. If they couldn't reproduce, we wouldn't have to deal with so many of them!
  • Quality Porpoise 2012-11-07 17:58
    My favorite: /...[a-zA-Z].../i
  • chubertdev 2012-11-07 18:05
    Silverhill:
    Or, as Sam Goldwyn (of MGM) put it, "You can't polish a turd."


    Wasn't that proven wrong by the Dodge Neon SRT-4?
  • Jazz 2012-11-07 18:24
    atk:
    Like snakes and mongooses , QA and developers are natural enemies.

    If the product is lacking in quality, either customers won't buy it, or they'll demand support. If they don't buy it, the company doesn't make money and nobody gets paid. If customers demand support, that costs the company money. If it costs the company too much money, and support is equally or more expensive than profits, the company loses money and nobody gets paid.
    ...
    Whether developers, professors, or anyone else realize it or not, this is the same goal as development has - to make the company money and get paid.


    I certainly don't think that QA and developers are natural enemies, but I reject categorically the notion that my goal as a developer should be to raise corporate revenue by ensuring product quality. I don't think your model holds. It breaks down because the feedback from customer to developer is not instantaneous.

    If the product is lacking in quality and customers don't buy it, it will take at least a few weeks before the impact of that revenue loss is felt. If the product is lacking in quality and the customers demand support, it will take months before management even notices the demands, let alone spends any money on providing that support. And even then it's a fair bet that management just decides to not spend the money to provide support at all, and they leave the customers out in the cold. And if the cost of ongoing support is truly greater than the revenue, it may take a year or more before that discrepancy sinks the company entirely.

    Meanwhile, I already got paid for the code I turned in at the end of my two-week pay period, before any of these issues have been noticed. My goal is to get paid. I got paid for my work regardless of the quality of the end product.

    atk:
    All quality and all bugs come from development. Development is fully responsible for the quality (or lack thereof) in a product. Nobody else writes the code. Nobody else creates the bugs. (For the pedants, product management is responsible for requesting a product that customers will want, but they're still not the ones that do or do not build in quality.)


    Utter bollocks. Development controls only one aspect of quality, which is number of bugs created. Management (and in many companies, Sales & Marketing) controls everything else, including number of bugs fixed. In particular:

    Development doesn't control the feature set of the product. When a manager says, "we need to have X, Y, and Z in our app," then it's development's job to put X, Y, and Z in the app. It's management's job to know, and care, whether customers actually want X, Y, and Z or whether they want A, B, and C instead. If that isn't what customers turn out to want, it's not like I'm allowed to say "no" and just go code up A, B, and C. I would be fired for that. So that mismatch between what the customer wanted and what we gave them is management's fault. (Dammit Jim, I'm a developer, not a market researcher.)

    Development doesn't control the time frame. When a manager says "ship it on Tuesday, or else," we ship it on Tuesday. It's management's job to take factors like possible brand image issues into account when making these decisions (and any half-decent business school should have taught them this). If the product wasn't ready to go, it's not like I'm allowed to say "no" and keep fixing bugs on Wednesday and Thursday and just arbitrarily run over deadline. Management decided to ship it before it was done; if that leads to issues with quality, those issues are the fault of the one who made the decision, i.e. management.

    So at the end of the day, why should I care about the customer's perception of quality? If that customer finds a product to have a quality issue, nine times out of ten, it's because management insisted on something that development told them twice was a bad plan. That customer's beef doesn't lessen the pay that we already received weeks ago for doing the work, nor is it anything we could have changed since management overruled our objections.

    TL;DR: I'm not about to lie awake at night biting my nails over something that I can't control and that doesn't affect me, and I'm kind of incredulous that you believe I should.

  • TheCPUWizard 2012-11-07 18:55
    Quincy:
    C-Derb:
    JoeT:

    Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
    I have worked with QA people who find trivial issues like this that were never defined in the requirements
    Maybe there's a hint there.

    Close the bug report as "invalid bug submission: missing requirement ID"


    Close, but not quite...The bug should be active and target the requirements document. If something is ambiguous, then it will create a never ending list of support issues.

    Update the requirements to either allow [no coding change] or reject [coding change] lowercase, and you are golden for ever.
  • Meep 2012-11-07 18:56
    Bubbles:
    What's with the dev/QA hate? I love our QA team, they're very good and they help us devs a ton. And we go out for beers together too.


    Likewise. I like the QA folks and the SMEs, too. I like the thought that I'm not just writing code, but producing something that has real world application.
  • atk 2012-11-07 21:08
    Utter bollocks. Development controls only one aspect of quality, which is number of bugs created. Management (and in many companies, Sales & Marketing) controls everything else, including number of bugs fixed.


    Clearly we have different definitions of "development". I use the "development team, including its management structure" definition, and you are using "individual developers". Oh, and please go back and read the "for the pedants" sentence immediately after the sentence you quoted.

    No matter what you say, it remains true that development is what places the bugs in the code, because it is development that creates the code. Equally true, development places the quality in the code, because it is development that creates (or fixes) the code.
  • atk 2012-11-07 21:16
    I certainly don't think that QA and developers are natural enemies, but I reject categorically the notion that my goal as a developer should be to raise corporate revenue by ensuring product quality. I don't think your model holds.


    I left out free software, so the model doesn't hold for everything. But in "for profit" companies, where development is paid by the company, and the company makes its money by selling software, the overall joint purpose is to sell the software.

    You accurately state that there are timeframes through which the impact of lack of quality is felt. I did not say anything about timeframes in my original post, as it is not directly pertinent to the point - animosity between the teams, simply because they are different teams, is counter productive.

    The examples people provided earlier in this thread, meant to justify distain for QE, are not examples of what's wrong with QE. They're examples of less effective QE persons, difficult to explain/diagnose issues, and communications problems. As in any specialty, some people in QE will be great, most will be average, and some will be muffinheads. Cherry picking stories about a couple muffinheads is a reasonable way to classify a whole group.
  • atk 2012-11-07 21:20
    Please look up the meanings of "high strung" and "annoyed (at a common problem) ". You'll find that there's a difference.
  • atk 2012-11-07 21:21
    [quote user="dkallen"][quote user="atk"][quote]
    ...this is the same goal as development has - to take the company's money and get laid.
    [/quote]

    [/quote]

    Glad to see you got one thing right.
  • da Doctah 2012-11-08 01:23
    [quote user="Tom"][quote user="RichP"]Shouldn't the plural of "mongoose" be "mongeese"?[/quote

    And a baby mongoose would then be a "mongosling?"[/quote]

    A female peacock is called a "peahen". The babies are "peachicks". It is not recorded whether they are fond of chickpeas.
  • da Doctah 2012-11-08 01:25
    C-Derb:
    or 3)an email with "Hey, this is a bug..." immediately followed by 1) or 2) asking "did you get my email?"


    I contend that the only valid response to such a message is either "yes" or "no", with no additional information, followed by severing all further contact.
  • jarfil 2012-11-08 04:30
    Developers think how some code may solve problems.
    QA think of ways how some code may create problems.

    You should NEVER ever let anybody with a QA hat anywhere near writing code.

    I've been there, I've done that... and it ain't pretty (also if I hadn't deleted it shortly after, it may pretty well have ended up on this site)
  • Swedish tard 2012-11-08 06:14
    atk:
    Utter bollocks. Development controls only one aspect of quality, which is number of bugs created. Management (and in many companies, Sales & Marketing) controls everything else, including number of bugs fixed.


    Clearly we have different definitions of "development". I use the "development team, including its management structure" definition, and you are using "individual developers". Oh, and please go back and read the "for the pedants" sentence immediately after the sentence you quoted.

    No matter what you say, it remains true that development is what places the bugs in the code, because it is development that creates the code. Equally true, development places the quality in the code, because it is development that creates (or fixes) the code.


    I find it that it's my responsibility as a developer to give management and other interrested parties information about the current quailty of the product, but it's their responsibility to decide when the quality is good enough.
    They are, after all, the ones that deal with the money aspect.
    Code does not need to be perfect to make money, and that is what companies does, makes money...
    Spending to much time on perfecting software will make it so expensive that noone will buy it, and you lose money instead.
    I'm not particularly happy about it, since I want my code perfect. But as any other craftsmanship, you need to know what is essential and must be working correctly, and what needs less attention. If you cant differentiate those two, you are not a good developer.
  • Atk 2012-11-08 07:29
    [quote user="Swedish tard"][quote user="atk"]

    I find it that it's my responsibility as a developer to give management and other interrested parties information about the current quailty of the product, but it's their responsibility to decide when the quality is good enough.
    They are, after all, the ones that deal with the money aspect.
    Code does not need to be perfect to make money, and that is what companies does, makes money...
    Spending to much time on perfecting software will make it so expensive that noone will buy it, and you lose money instead.
    I'm not particularly happy about it, since I want my code peerfect But as any other craftsmanship, you need to know what is essential and must be working correctly, and what needs less attention. If you cant differentiate those two, you are not a good developer.[/quote]

    I entirely agree with the above statement. While my original rant was focused on the relationship between dev amd qa, it is absolutely true that there is a 'good enough' point for any project.

    NB: seriously? The captcha cares about caps on the first letter, when many phones and tablets auto-capitalize it?
  • Swedish tard 2012-11-08 07:51
    Atk:

    I entirely agree with the above statement. While my original rant was focused on the relationship between dev amd qa, it is absolutely true that there is a 'good enough' point for any project.

    NB: seriously? The captcha cares about caps on the first letter, when many phones and tablets auto-capitalize it?


    Yeah, I love Q/A as well. They help me improve by pointing out what I get wrong.
    I've noticed that a lot of developers skip testing their on stuff, since there is another testing instance though. That's not how to use Q/A. As a developer you should strive for a level of quality where Q/A really just needs to rubberstamp your stuff and send it off. That scenario will never happen though, since all code has problems. And a decent Q/A will find even the most obscure things.

    And as with any other entity that interfaces with developers, there is the problem with different languages (even if they are both using english). Q/A may say something that a developer interprets in way that sounds ridiculus to a developer, but when digging a bit more it is a very reasonable feedback.
    Just because something isnt in the requirement doesnt mean it's wrong. Just a sign that your requirements need work.
  • fa2k 2012-11-08 11:15
    I think it should be mongii, in analogy with virii and walrii.
  • RegAxel 2012-11-08 13:05
    I tried to break it down...

    /^
    [\s]* // any whitespace
    (?: // non-capturing
    (P.+?) // P+character at least once/zero or one
    [\s]+ // at least one whitespace
    (?: // non-capturing
    [_] // one underscore
    [\s]* // any whitespace
    [\n\r]+ // newlines
    )?
    )?

    (F.+) // F+character at least once
    [\s]+ // at least one whitespace

    (?: // non-capturing
    [_] // _
    [\s]* // any whitespace
    [\n\r]+ // at least one newline
    )?

    ( // capturing
    [a-zA-Z] // any series of letters
    [\w]{0,254} // by up to 254 word characters
    )

    (?: // non-capturing
    [\s\n\r_]* // white space, newlines and/or underscores

    \( // (

    (?: // non-capturing
    [\s\n\r_]* // white space, newlines and/or underscores
    ( // capturing
    [a-zA-Z] // any series of letters
    [\w]{0,254} // by up to 254 word characters
    )
    [,]? // optional comma
    [\s]* // any whitespace
    )* // any of the pattern

    \) // )
    )?/gi
  • Paul Neumann 2012-11-08 13:20
    atk:
    Like snakes and mongooses , QA and developers are natural enemies.


    I've heard that bu11$#!t before, and it's still BS - even with the possibility that it's here only for humor. <snip reason="If you really care about the original, click the &quot;394352&quot; link above" /> -- to make the company money and get paid.

    BTW, I'm a developer.
    This here is tdwtf. That level of rationale and professionalism will not be tolerated!
  • Slapout 2012-11-08 13:22
    dkackman:
    "Like snakes and mongooses , QA and developers are natural enemies."

    Best quote ever. Putting on my whiteboard


    Developers vs QA
    Developers vs DBAs
    Developers vs Network Ops
    Developers vs Management
    Developers vs Users

    We're surrounded!!
  • Dann of Thursday 2012-11-08 15:54
    Apparently some of you work in magical fairylands where the QA team isn't entirely comprised of underqualified college dropouts that think they can make up requirements on the spot and then record bugs against these imaginary missing functionality. I have worked for a lot of clients and only one single one had a QA team that wasn't entirely worthless.

    Anecdote time: I once received a defect that claimed that a list box wasn't populating correctly. I looked at the code, saw that it was a simple, easy-to-fix problem (and it wasn't my code!) and implemented a fix, returning the ticket to the QA tester. Ten minutes later they sent me AND my manager an !URGENT! email about how the bug wasn't fixed, with a screenshot attached.

    The list box was clearly populated in the screenshot. I mean the damn thing was completely full. I briefly considered tendering my resignation rather than continuing to submit to such lunacy, but instead I opened the screenshot in MSPaint, added a huge red box around the relevant form item, and sent it back to the tester without any text. Bug closed, lesson learned.
  • atk 2012-11-08 17:57
    Swedish tard:


    Yeah, I love Q/A as well. They help me improve by pointing out what I get wrong.
    I've noticed that a lot of developers skip testing their on stuff, since there is another testing instance though. That's not how to use Q/A. As a developer you should strive for a level of quality where Q/A really just needs to rubberstamp your stuff and send it off. That scenario will never happen though, since all code has problems. And a decent Q/A will find even the most obscure things.

    And as with any other entity that interfaces with developers, there is the problem with different languages (even if they are both using english). Q/A may say something that a developer interprets in way that sounds ridiculus to a developer, but when digging a bit more it is a very reasonable feedback.
    Just because something isnt in the requirement doesnt mean it's wrong. Just a sign that your requirements need work.


    Again, we are in full agreement :)
  • atk 2012-11-08 18:00
    Dann of Thursday:
    Apparently some of you work in magical fairylands where the QA team isn't entirely comprised of underqualified college dropouts that think they can make up requirements on the spot and then record bugs against these imaginary missing functionality. I have worked for a lot of clients and only one single one had a QA team that wasn't entirely worthless.

    Anecdote time: I once received a defect that claimed that a list box wasn't populating correctly. I looked at the code, saw that it was a simple, easy-to-fix problem (and it wasn't my code!) and implemented a fix, returning the ticket to the QA tester. Ten minutes later they sent me AND my manager an !URGENT! email about how the bug wasn't fixed, with a screenshot attached.

    The list box was clearly populated in the screenshot. I mean the damn thing was completely full. I briefly considered tendering my resignation rather than continuing to submit to such lunacy, but instead I opened the screenshot in MSPaint, added a huge red box around the relevant form item, and sent it back to the tester without any text. Bug closed, lesson learned.


    Sometimes these problems are caused by the QA team being composed of incompetents. Sometimes these problems are caused due to lack of good documentation from development. Sometimes these problems are caused by lack of development training QA on the product. Sometimes these problems are cause because dev makes one assumption and qa makes another (especially common in different cultures, as pointed out above).

    Yes, I've worked with qa in these states. I've also worked with excellent QA teams that some people in Dev thought were incompetent due to communications problems.
  • ekolis 2012-11-08 18:42
    Fun programmer drinking game: Take turns converting random GIF's to ASCII art using a tool built for such a purpose. Feed said ASCII art into a Perl interpreter. If no errors, take a drink.
  • Veldan 2012-11-08 18:45
    +1 for Invader Zim comments :D
  • I'm an SDET, I look down on both sides 2012-11-09 06:57
    I've worked at companies with good dev teams and good QA teams. I've worked at companies with shit QA teams and shit dev teams. I've never seen a company with shit QA and good devs - most of the bitching here is a severe case of the Dunning-Kruger effect.
  • Tynam 2012-11-09 07:49
    atk:
    Like snakes and mongooses , QA and developers are natural enemies.


    I've heard that bu11$#!t before, and it's still BS - even with the possibility that it's here only for humor. You'd expect to see attitudes like this from immature, fresh-out-of-school programmers. But sadly, we see it from many experienced developers, management, and even college professors. It's attitudes like this that create unnecessary tension between teams whose joint purpose is to deliver a product to market that people will buy.
    ...


    Exactly right. I think this attitude arises because if QA are doing their jobs right they tend to argue with, or demand things from, the dev team a lot. And we all get defensive when our code is criticised. But that doesn't make us enemies; we have the same goal. My sister tells me I'm wrong a lot too; she's still on my side.

    (I argue with my dev lead frequently, and occasionally loudly. That's not a flaw; she was in charge of QA hiring and picked me for QA lead because she thought I *could* argue with her. Often these arguments end when she tells me I'm wrong and goes on to prove it... which is a sign we've both done our jobs right.)
  • Your Mom 2012-11-09 12:50
    Wait, I'm a script?
  • Trident 2012-11-09 13:24
    Typical result of programmers from universities without practical knowledge.
  • Danny 2012-11-09 16:43
    What, no Cornify this time? I clicked on damn near everything trying to find it, only to finally give up and check the source—much to my dismay.

    Remy, you're such a choex.
  • justme 2012-11-09 17:51
    C-Derb:
    Quincy:
    C-Derb:
    JoeT:

    Bug 1: "The parser accepts both lowercase and uppercase commands. The [competing product] rejects lowercase. Please reject lowercase commands."
    I have worked with QA people who find trivial issues like this that were never defined in the requirements
    Maybe there's a hint there.

    Close the bug report as "invalid bug submission: missing requirement ID"
    You've got a point, as long as you are working somewhere that wants to use a software system to actually log bugs. Right now, the bugs get logged one of three ways: 1) the QA person interrupting my work with "Hey, this is a bug...", or 2)an IM interrupting my work with "Hey, this is a bug..." or 3)an email with "Hey, this is a bug..." immediately followed by 1) or 2) asking "did you get my email?"

    Either way though, once the conversation moves to "this is a bug"/"No it isn't", the bad blood starts to develop. Bottom line: QA is there to test that software meets requirements. When QA tries to define requirements, I get annoyed.


    No, QA is there for validation ( are we build what we need ) not verification ( are we building what we said we would )
  • Seele 2012-11-09 23:26
    Don't shoot Mongoo - it just makes them angry!