• (cs)

    Thanks for sharing this sad story with us. Sadly as said by many that this kind of thing is not uncommon in IT industry.

    Many people, once have title conferred on them, instantly believing the words coming out of their mouths are truth and would be 100% correct and would produce goods.

    So many are obviously with no technical competency to deal with these situations and too damn proud to learn.

    I have even heard of managers taking a project using technology X to a brand new technology Y without changing the architecture to exploit Y. The end result was like running a sport car on kerosene but still refusing to concede the mistake.

    Often far too many developers go along without telling the emperor has no cloths.

  • (cs) in reply to Anon
    Anonymous:

    I forgot to mention that because I was on a deadline to get "100% passed" by "xx/xx/xxxx", I took it upon myself to hunt down the cause of this issue.  Unfortunately, the no-brained dev got all the credit for "finding and fixing" this bug (which would have cost the company multi-millions); as a QA engineer, I didn't have enough access privileges to actually add the missing "else", add it to the mainline release branch, and recompile.  So, the Dev got an extra day of vacation, some stock options, and a nice cash award, while I received an extra month of 80+ hours/week and a bad review for my attitude.


    heh that's the exact opposite of what i had to deal with recently.  The QA team lead reported to me that there was a problem with my code, intermittently failed on his machine. 
    Intermittent sounds bad so I check with him is it certain input documents. 
    "No it's I all documents but intermittent" he replies. 
    So I figure it must be a configuration issue.  Spend ages configuring my machine the same as the test machines. still don't see the problem. 
    Some time later of working on it I am getting one of the testers to show me the problem again and I notice it works with one document but not with another.  Got him to send me the bad document and sure enough it was document specific.
    2 days of going round in circles because I believed the QA lead.  I'll know in future to trust my gut first and take what they say with a hefty dose of salt.
    Maybe we should put the dev from your company together with the QA lead of my company and leave them to rot?
  • alrightyThen (unregistered)

    <FONT face=Tahoma color=#000080 size=2>They put the "K" in Kwality... That doesn't look right. Is it a "Q" or something. Qwality? That looks better.</FONT>

    <FONT face=Tahoma color=#000080 size=2>Ship it.</FONT>

  • (cs) in reply to Anon

    Anonymous:
    Management: "You have until xx/xx/xxxx to have these tests 100% passed."

    Turns out, the cause of this issue was a missing "else" before a code segment.

    "You have until xx/xx/xxxx to have these tests 100% passed... or else."

  • Fred Trellis (unregistered) in reply to Kyle Reese

    Jimm's problem is very common. 

    And is the reason why techies so often do not become managers, and why managers look down on 'mere' techies. And if you don't understand that it is NOT a WTF, then you are too techie to be promoted.

     

  • (cs) in reply to themagni

    themagni:
    I was told to "do your own QA".

    I worked at a place where developers did their own QA.  I would test and test and try to think of every possible way to break the code.  When I thought I had it bulletproof, I would deliver my software to the manager of Production Control, who had an amazing ability to bring it to its knees in about eight seconds with a combination of pointless, idiotic keystrokes.

    "Good god, why would you do that?" I'd say.

    "Because my people will do it," was his answer.

    That was how I learned to code for not merely bulletproof, but idiot-proof.

  • BenB (unregistered) in reply to Hanneth

    Hanneth:
    Have you ever tried programming anything that accesses .Net? Or how about Visual C++?

    I had GCC insist that in my C++ code that a  "static const int is not a const int" so I went C style used #define instead. So much OOP in C++ with GCC...

    Puzzled the hell out the C++ experts I asked...

     

    Captcha = pacman

  • (cs) in reply to BenB
    BenB:

    I had GCC insist that in my C++ code that a  "static const int is not a const int" so I went C style used #define instead. So much OOP in C++ with GCC...



    I'm sorry but you need to explain that one. As a class member ? as a global ? You know that actually only static const ints can be defined in the class body ?

    You said too less and too much :)
  • (cs) in reply to TeeSee
    TeeSee:
    themagni:
    At my previous job, the QA guy quit in disgust after the owner refused to follow QA directions. (Like "wear a static strap" or "when you stay here until 3am rushing a job, you always make mistakes. Stop doing that.")That was just for the mechanical side. I kept pushing for a firmware QA so my work could get reviewed. I was told to "do your own QA".

    Of course, bugs got out and it was All My Fault. If I'd put in the 60+ hour weeks that they suddenly started demanding, of course I'd have found them all. Last I heard, they were still looking for my replacement. For some reason, they're having trouble finding firmware engineers with 3+ years of experience willing to work 60+ hours a week for 40k (CDN) with no benefits or profit-sharing.

    40k is pants. Assuming my current company likes me, after I graduate I'm looking at 25K, bonuses, profit-dependent bonuses, and all for 37.5 hours/week.

    And I like to think I'm worth more than that ;)


    I don't understand the "pants" reference. Is that good or bad? It assumes that I know what you like to dress like. Do you wear shorts to work? Help me out here.

    You might be worth more than you think, at least if you're an Engineer.

    The job I refer to had about 250-275 responsibility points. It's probably near the top of that range, since they increased the requirements after I left.

  • ebfe (unregistered)

    there are two doors:

    the door to your left leads back to your office and our production deployment plan.
    the door to your right leads to the end of the building and the end of your employment.

    as you adequately put: the problem is choice.

  • BtM (unregistered)

    At one company I worked for, the battle cry was "We'll fix it in the field!"

    Bonuses were tied to ship dates, so project managers were encouraged to set and beat impossibly aggressive schedules.  So long as what we shipped could be installed and didn't crash immediately on startup, that was okay.  Any other problems could be addressed with a patch. 

    Our release status was RED on the VP's spreadsheet because we had a huge backlog of defects.  Anything that wasn't a Sev 1 Priority 1 (i.e., crash, burn, and die) defect was deferred indefinitely (we had a lot of crash, burn, and die problems).  Things were looking pretty grim until the development manager came up with a brilliant idea.

    He just closed all the non-crash-burn-die defects.  After all, we weren't going to address them anyway, so why keep them around and make us look bad?  Our release status went back to GREEN, he got an attaboy, we got T-shirts, and the QA department got reamed for opening several hundred "frivolous" defects. 

    I think that was the closest I came to seeing a murder in workplace.  The QA staff spent the entire next day  holed up in their manager's office so they could vent. 

    The story does have a happyish ending.  We had been acquired by a company that actually cared about product quality, and after a while that manager was busted back to code monkey status.  That particular product died a slow, lingering death, but fortunately only one customer was gullible enough to buy it. 

  • (cs) in reply to Kyle Reese

    Anonymous:
    Listen. And understand. That terminator is out there. It can't be bargained with. It can't be reasoned with. It doesn't feel pity, or remorse, or fear. And it absolutely will not stop, ever, until you are dead.

    Listen.  And understand.  That program manager is out there.  It can't be bargained with.  It can't be reasoned with.  It doesn't feel pity, or remorse, or fear.  And it absolutely will not stop, ever, until you are inconsequential.

     

  • anonymous (unregistered) in reply to blah
    Anonymous:

    or my favorite:

    Dev: "This trouble ticket is being closed because the software works as coded."
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."


    Well.. EASY.
    Thas mean the devs put a bug there, as a undocumented feature.

    No one will put a bug on purpose, except if the design is soo wrong that is absolute must. And only on a really warped way a bug is a feature.
    Sadly enough, that wroness and warped is very common. So Is posible, on this very reality we all share.

    A example of bug = feature is a program that crash if some guy is triing to steal money with it. ( think a cash machine ) And will be a undocumented feature. Not in spec.




  • limitless (unregistered) in reply to anonymous
    Anonymous:
    And only on a really warped way a bug is a feature.


    MSN Messenger Live new feature: "You can now talk to your contacts while appearing offilne".
    Everybody called it a bug when it happened in Messenger 6.


    That "works as coded" is really a WTF vintage....
  • Kazan (unregistered) in reply to its me
    its me:
    Anonymous:

    Dev: "This trouble ticket is being closed because the software works as coded."
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."


    That's classic.... Show me just how a bug is a result of software not working how it's coded....

    -me


    bad compiler optimizations.. i've seen it created CTD bugs in a game  
  • Botia (unregistered) in reply to sparkfizt
    sparkfizt:

    sweet, technically everything works "as coded" unless you have some freaky compiler that likes to jumble up the code as it compiles.

    Guess you haven't done much Windows CE coding. ;)

  • Rick (unregistered) in reply to TeeSee
    TeeSee:
    themagni:
    At my previous job, the QA guy quit in disgust after the owner refused to follow QA directions. (Like "wear a static strap" or "when you stay here until 3am rushing a job, you always make mistakes. Stop doing that.")That was just for the mechanical side. I kept pushing for a firmware QA so my work could get reviewed. I was told to "do your own QA".

    Of course, bugs got out and it was All My Fault. If I'd put in the 60+ hour weeks that they suddenly started demanding, of course I'd have found them all. Last I heard, they were still looking for my replacement. For some reason, they're having trouble finding firmware engineers with 3+ years of experience willing to work 60+ hours a week for 40k (CDN) with no benefits or profit-sharing.


    40k is pants. Assuming my current company likes me, after I graduate I'm looking at 25K, bonuses, profit-dependent bonuses, and all for 37.5 hours/week.

    And I like to think I'm worth more than that ;)


    Isn't 40 CDD about 25 USD? And WTF would "pants" mean in this context?
  • I feel your pain (unregistered) in reply to Anon

    What a whipping!

    For some reason, it always turns out that the guy who's busting his a$$ gets 'rewarded' with more work and poor reviews, while the "squeaker", e.g. the guy that barely squeaks by without getting fired, gets good reviews, bennies, and probably less work.

    Typical.

  • (cs) in reply to Foxy
    Anonymous:
    Later, suspecting that there must be something odd about the source, I opened it in a HEX editor. There were two odd control characters that Visual Studio was allowing to happily live in my source and ignore when I was editing. I removed them, and the original file finally compiled into a functioning program.


    I think that's a pretty standard type of problem. It's also why Emacs and less both carefully preserve and display any weird control characters in files. (Useful feature!)

    TeeSee:
    VisualStudio's help says SqlConnection.Dispose() is "functionally identical" to SqlConnection.Close(). This is a blatant lie. Dispose() unsets member variables, so you can't recreate them with Open(), while Close() doesn't unset member variables.

    Of course, it depends on whose code you're thinking of, but it's still the same.
    Sounds about par for the course...
  • More Anonymous (unregistered) in reply to Ford351-4V

    That's "bite my shiny metal ass", meat bag.

  • Franz Kafka (unregistered) in reply to SwordfishBob
    Anonymous:
    > That's classic.... Show me just how a bug is a result of software not working how it's coded....

    Actually, the original use of the word "bug" answers your question. In the olden days, before IC "chips", faults were often caused by bugs crawling across the wiring, or getting fried across the wires.



    Nah, the usage of 'bug' predates computers by a century or more - Newton made mention of them, even.  

  • (cs) in reply to Anonymouse
    Anonymous:
    Do you remember what these control characters were? This would be a handy goodbye gift to all those Bastard Employers From Hell...


    decimal 61613, of course.

    ok
    dpm
  • (cs) in reply to Rick

    > Isn't 40 CDD about 25 USD? And WTF would "pants" mean in this context?

    Pants is british for "crap".

    40k pounds is about 100k$Aud, which is what? 75k$usd?

  • (cs)
    Alex Papadimoulis:

    I've decided. My first official act as Chief Executive Officer will be to hire a Yes Man.



    You don't need to hire a Yes Man. You can just buy ClickYes!
  • Sparky (unregistered) in reply to Former QA Manager

    ... and that reminds me of a trip to Death Valley, gas stop outside Ridgecrest or Trona. Gas nozzle jumped out of my filler pipe. Twice. Spraying gas. Never seen that before or since.

    Told the teen girl at the register she might want to have someone look at the pumps. She shrugged. I replied: I'm gassing here once. You work here. Like fire?

  • BenB (unregistered) in reply to Silex
    Silex:
    BenB:

    I had GCC insist that in my C++ code that a  "static const int is not a const int" so I went C style used #define instead. So much OOP in C++ with GCC...



    I'm sorry but you need to explain that one. As a class member ? as a global ? You know that actually only static const ints can be defined in the class body ?

    You said too less and too much :)

    Um C++ generally implies OOP unless using C++ as a sanitised C.

    So, yes, in a class definition - in the header file, and they were in the public section of the class. I was using them as the C++ book specified. More importantly as I had successfully used them before...

    I later ported the code to Java with minimal changes and used the standard Java style: "public static final int".

  • LRB (unregistered) in reply to marvin_rabbit

    marvin_rabbit:
    Anonymous:
    I once came on a project that was budgeted for $1,000,000.00 and 6 months and after 9 months and $2,500,000.00 of development they started to gather requirements.  Somehow none of the functionality coded matched what was needed.  The project manager then came up with the "brillant" idea that we should "decouple development from requirements" that that we could finish the project "quickly".  His manager bought the idea, and I decided to pursue employment else where. 
    \
    But, but....  stammer...  Isn't "decouple development from requirements" the definition of what you had done in the first place?

    Well actually what had been done was develop 75% of code, then start requirements which were to be a "rubber stamp approval" of what development was done.  Unfortunately the business had a totally different view of what was needed than the project manater/architect.  I suppose that they never were coupled together, but this decoupling was formal approval from upper management. 

    BTW I was very unpopular from the start by bringing up many of the issues that the business folks said were essential.  And just coincidentally, there was no QA members on this team nor a QA environment to work in. 

  • (cs) in reply to Anon

    O M F G ... Wow ...

    The sad part is it IS common ... Its like they'd rather deal with the thousands of support tickets and crap after the software is released, than to just fix it the first time, release it, then have customers pay for a service contract they never have to use ... Here we have it backwards when it comes to software atleast ... We want the stuff tested to high hell, the problem is our testing staff is lucky they can turn a computer on, most still spend their days trying to find the 'any' key.

  • 8bitwizard (unregistered) in reply to Former QA Manager
    Anonymous:
    I did not make any friends when I told our admin champion of QA that our testing did not make any difference in the quality of the released software. I came to the conclusion that unless the gas pump software caused the pump to spray the customer with gasoline and then light it on fire, there was no way the software was not shipping. And even then, it would be a close call...


    Ha ha.  In my case, the gas pump almost did that (the handle didn't click when the tank was full), and it was pushed all the way up to me with nobody in tech support catching on to the bit of trivia that our system not only didn't, but couldn't control the freaking handle, which was something purely mechanical.

    But my best WTF moment was when I showed a $2 bill to one of our H-1B programmers who was working on cash acceptor software.

    Fortunately, my company did at least listen to QA when they found something, even if it was mostly "monkey testing" and things slipped through all the time.  (like customers being able to get free gas and not even know it was free)  But at least we had a talented "monkey" tester.  She had a knack for doing lots of strange things to find strange bugs, and if there was a bug caused by dancing on the gas pump while pleasuring the card slot by repeatedly inserting and removing the card, she'd find it.

    (or maybe we're talking about the same company and you're a Virginia Hey fan)
  • (cs) in reply to Eric the .5b

    Eric the .5b wrote the following post at 08-15-2006 8:12 PM::
    Anon:
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."
    Works as CODED?  WTF does that mean?!

    It obviously means that it does NOT work as designed, or as specified, or in any way that would make any sense or that would be of any use to anybody.

    But I do seem to remember a vendor once telling us that something "worked as implemented."  (This was an issue when their usual excuse of "it works as designed" obviously just wouldn't cut it.)

  • 8bitwizard (unregistered) in reply to Foxy
    Anonymous:
    Later, suspecting that there must be something odd about the source, I opened it in a HEX editor. There were two odd control characters that Visual Studio was allowing to happily live in my source and ignore when I was editing. I removed them, and the original file finally compiled into a functioning program.

    There is something strange that can happen in OS X's TextEdit.app text editor.  I don't know how, but every now and then, a control-P (which is of course invisible) gets inserted into the text, and the code I am working on fails to compile for mysterious reasons.  This has been happening for years, and I still don't know what causes it.  The only way I can find it is either with a text editor, or by slowly repeatedly pressing an arrow key to see where it pauses.


    But I'm surprised that in your mystery case, the code actually compiled.  That is much more insidious.
  • (cs) in reply to Anon

    Anon wrote the following post at 08-15-2006 9:45 PM::
    I took over management of a QA group in a company that shall remain nameless, and one of the things I learned in the first few weeks was that some enterprising tester had pulled the validation statements out of all of the tests, because the tests kept failing (who needs to fix the code...).  The funny (ok, sad really) was that they were still running these tests and considered them valuable because they were automated, even though they didn't actually check any conditions.

    This wouldn't happen to be the tester who was told he had until xx/xx/xxxx to have the tests 100 per cent passed?

  • Rye Barley (unregistered) in reply to SwordfishBob
    Anonymous:
    > 

    Actually, the original use of the word "bug" answers your question. In the olden days, before IC "chips", faults were often caused by bugs crawling across the wiring, or getting fried across the wires.



    "Actually", SwordfishBob, the original use of the word "bug" is not from "bugs crawling across the wiring, or getting fried across the wires". Originally, it derives from a different word from hundreds of years ago.

    Your misconception stems from a famous incident recounted by Admiral Grace Murray Hopper, who in 1947, actually found a moth that had prevented a relay from functioning. Many people erroneously think that she coined the term at that moment, and that's why we have bugs. However, her log book indicates that she knew that the term was already in use, stating "First actual case of bug being found". So, instead of making up the term, she was actually noting the irony of a bug being caused by a bug.

  • (cs) in reply to LRB

    LRB wrote the following post at 08-15-2006 10:35 PM::
    I once came on a project that was budgeted for $1,000,000.00 and 6 months and after 9 months and $2,500,000.00 of development they started to gather requirements.  Somehow none of the functionality coded matched what was needed.  The project manager then came up with the "brillant" idea that we should "decouple development from requirements" that that we could finish the project "quickly".  His manager bought the idea...

    Am I missing something here?  Wasn't development decoupled from requirements right from day 1 of the project?

  • (cs) in reply to FredSaw

    FredSaw:
    Anonymous:
    Management: "You have until xx/xx/xxxx to have these tests 100% passed."

    Turns out, the cause of this issue was a missing "else" before a code segment.
    "You have until xx/xx/xxxx to have these tests 100% passed... or else."

    That's a good one, except...  That "else" is actually after a code segment.

  • pedant (unregistered) in reply to Rick

    At today's exchange rate: $40 000 Cdn = $35 570.52 USD

  • (cs) in reply to Anon
    Anonymous:
    Management: "Why aren't your tests 100% passed?"
    Me: "Because the code is broken; I can't pass the test until the code is fixed."
    Management: "So when will you have 100% pass?"
    Me: "um ... When the code is fixed."
    Management: "You have until xx/xx/xxxx to have these tests 100% passed."

    or my favorite:
    Dev: "This trouble ticket is being closed because the software works as coded."
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."

    Turns out, the cause of this issue was a missing "else" before a code segment.

    shudder Imagine how much the state of the world would improve if we could implant fleas' brains into the skulls of such managers. Anyway I would just remove all checks and replace them with bogus "tests" that just say "Success!" just as desired. You get what you ask for. Then go on and find some new job opportunity.

    This reminds me of a guy who worked at a company other than the company I work at (fortunately). This was an equally incompetent dimwit as that manager, but he was actually a tester. Actually, although being totally braindead otherwise, he did have some technical competence. He wrote fine automatic tests, tests that would even find serious bugs. And, just imagine, he managed to find neat workarounds for all of these bugs, and he included the workarounds in the test cases. One day of course people began to wonder why customers reported bugs in functions that were supposed to be covered by the automatic tests (which, of course, passed 100% successfully). Well maybe now that they know all these neato workarounds, they can tell their customers exactly what to do:

    Customer: The "number of database columns" is always one too high. Support: Yes, we know. Just remember to subtract one before you use it for any important purpose. Customer: Huh? Oh, okay...

    The second dialog you mention is outrageous, too, but as a developer I must insist there are sometimes good reasons to reject tickets for genuine bugs. For example, my superior once found a bug in one of my components (a parser), and reported that like "XYZ information supplied by parser is incorrect", then wrote some prose (well, better than naught I guess) to describe his input file, but did not attach the input file.

    I looked at this, tried to write a file which triggered the same problem. I succeeded, fixed the code so that my own input file would work and marked the bug ticket "resolved". But I also wrote a comment asking that "If problem persists, please attach the input file which can be used to reproduce the problem."

    Well, almost needless to say, my superior reopened the bug some weeks later and wrote a totally useless comment like "Still have the same problem, please fix this."

    I tried this (again) with my own test file, and it still worked, of course. Then I closed the bug, marking it as "invalid", and wrote a comment like "No input file was provided, thus I cannot reproduce the problem."

    This wasn't very nice of me I guess :o), but then: Am I supposed to try and write my own test files until I might finally be able to reproduce the problem? And if I do manage to, who says that the fix will also work for the input file the bug reporter used? After all, there could be several bugs with the same symptoms. In effect, there had been at least two, one which I fixed, and another which still caused trouble. If there can be two bugs which cause this problem, there can be three or four as well. I had no way to ensure that I would fix the bug that was actually reported, because the bug reporter failed to provide essential information.

    And I might add that my superior then sent me the input file, I used it to reproduce the problem, managed to identify the cause of the problem, fixed it, and everyone lived happily ever after. So, though my response was somewhat rebellious, it did help me fix the code. :o)

  • (cs) in reply to Anon
    Anonymous:

    or my favorite:
    Dev: "This trouble ticket is being closed because the software works as coded."
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."


    Why exactly are people making so much of this remark? Are there companies somewhere that delay shipment of working software while the programmers second-guess how things coulda been? If there is such a company, how is its stock doing?

  • (cs) in reply to Dazed
    Anonymous:
    NAK. I had the same thing happen to me recently, and it persisted while I made changes to (other lines in) the code. To be fair to VB, I've had something very similar happen in at least two other languages.


    I've had VisualStudio do all sorts of weird stuff to me.  Execution jumps, incorrect call stack, ghost variables, lines of code not being executed, lines of code not doing what they should.

    When something like this happens I end up closing VS and doing a full get and rebuild.  Sometimes it even requires a reboot.
  • Marcus Redivo (unregistered) in reply to Rodyland
    Rodyland:
    Anonymous:
    NAK. I had the same thing happen to me recently, and it persisted while I made changes to (other lines in) the code. To be fair to VB, I've had something very similar happen in at least two other languages.


    I've had VisualStudio do all sorts of weird stuff to me.  Execution jumps, incorrect call stack, ghost variables, lines of code not being executed, lines of code not doing what they should.

    When something like this happens I end up closing VS and doing a full get and rebuild.  Sometimes it even requires a reboot.


    Those are the symptoms of running an optimized build in the debugger. Next time, check your rebuild options and do a full debug build.
  • (cs) in reply to John Hensley
    John Hensley:
    Anonymous:

    or my favorite:
    Dev: "This trouble ticket is being closed because the software works as coded."
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."


    Why exactly are people making so much of this remark? Are there companies somewhere that delay shipment of working software while the programmers second-guess how things coulda been? If there is such a company, how is its stock doing?



    You are kidding, right? Software that doesn't do what it's supposed to do is wrong, whether the developer agrees or not. Saying "It doesn't matter if it works like it's supposed to - it works like it was written." is ridiculous. And if you're not kidding, consider a career change. Real soon.
  • (cs) in reply to Anon
    Anonymous:

    or my favorite:
    Dev: "This trouble ticket is being closed because the software works as coded."
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."


    An equivalent statement to this is the standard response of one of the members of the support team for the company-wide bug tracking system where I work, when you report a bug in the bug tracking system itself.

    *bang*
    *head*
    *against*
    *wall*

    The statement being "This is how the system was set up". Yes. I can see that. That's why I'm reporting a bug. Why have you closed the ticket?

    *bang*
    *bang*
    *bang*

  • (cs) in reply to KenW
    KenW:

    You are kidding, right? Software that doesn't do what it's supposed to do is wrong, whether the developer agrees or not. Saying "It doesn't matter if it works like it's supposed to - it works like it was written." is ridiculous. And if you're not kidding, consider a career change. Real soon.

    Bite me. It's not a QA's job to evaluate software's design, only its outward behavior. If the behavior of the current code (the software as coded) is correct and reliable, it's time to move on.

  • Mulder (unregistered) in reply to John Hensley

    I've had this "stop looking for bugs" issue a few days ago as well.

    Some external developer was hired to relaunch our shop platform. When he turned in the code for review, it was full of security holes (SQL injections, XSS vulnerabilities, passwords passed in hidden form fields etc.). We reported those issues back to the dev, he fixed some, but left the majority in. Worse, he added more problems in the process, like forking Apache processes like mad.
    On the second meeting with my CEO, his clear message was: "Stop looking for every bug you can find, just get the thing on the road." Now I wonder whose head he's going to demand if our network gets hacked because of such a crappy app in our server farm...
    More or less this was like "I think you're just looking for bugs for fun". WTF?? If security issues aren't part of my job, I must've missed something important.

  • Anonymous (unregistered) in reply to John Hensley
    John Hensley:
    Anonymous:

    or my favorite:
    Dev: "This trouble ticket is being closed because the software works as coded."
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."


    Why exactly are people making so much of this remark? Are there companies somewhere that delay shipment of working software while the programmers second-guess how things coulda been? If there is such a company, how is its stock doing?


    As I'm the one who posted this "works as coded" dialog, I'll add a little detail....

    In this particular company, there is a whole heck of a lot of time and effort spent on specifications and requirements that precedes the step of actually sitting down at the computer to type-in the implementation, with QA (me) doing the test suites parallel to code design/implementation.  (I'd imagine most big companies do this, but my experience in this arena is a bit narrow.)  The particular code segment that spawned the "works as coded" statement was something akin to:

    if (condition_A)
    {
      optionA = true;
      ...
    }
    else
    {
      optionA = false;
      ...
    }

    (it was more than just setting a variable to true or false, but you get the idea) ...

    so, when the dev forget the "else" statement, it of course didn't work the way it was intended/designed to ... if condition_A was true, optionA was set to true but subsequently set back to false ... but, it "works as coded"

    somebody else had mentioned something to the effect that sometimes a design is faulty and the implementation is correct ... that is true ... but that's not justification to close a trouble ticket with "works as coded" ... the correct response would be to have the trouble ticket changed from "the code doesn't meet specs/requirements" to "the specs/requirements are faulty and need addressed" (and thus reassigned) ...

  • The Biggest WTF (unregistered) in reply to John Hensley
    John Hensley:
    Anonymous:

    or my favorite:
    Dev: "This trouble ticket is being closed because the software works as coded."
    Me: "... but it doesn't work as designed."
    Dev: "So? It works as coded and that's all that matters."


    Why exactly are people making so much of this remark? Are there companies somewhere that delay shipment of working software while the programmers second-guess how things coulda been? If there is such a company, how is its stock doing?



    Answer to Question #1:
    Because it is so common it's not funny.

    Answer to Question #2:
    Yes.

    Answer to Question #3:
    In many cases, you'd be surprised (considering the apparent naivete in the questions).

    captcha = enterprisey ... dead on!
  • (cs) in reply to The Biggest WTF
    Anonymous:
    John Hensley:

    Are there companies somewhere that delay shipment of working software while the programmers second-guess how things coulda been?


    Yes.

    So many you can't even name one?
  • Anonymous (unregistered) in reply to John Hensley
    John Hensley:
    Anonymous:
    John Hensley:

    Are there companies somewhere that delay shipment of working software while the programmers second-guess how things coulda been?


    Yes.

    So many you can't even name one?

    Depends on your definition of "working software".  "Works as coded"?
  • (cs) in reply to Anonymous
    Anonymous:

    As I'm the one who posted this "works as coded" dialog, I'll add a little detail....

    In this particular company, there is a whole heck of a lot of time and effort spent on specifications and requirements that precedes the step of actually sitting down at the computer to type-in the implementation, with QA (me) doing the test suites parallel to code design/implementation.  (I'd imagine most big companies do this, but my experience in this arena is a bit narrow.)  The particular code segment that spawned the "works as coded" statement was something akin to:

    if (condition_A)
    {
      optionA = true;
      ...
    }
    else
    {
      optionA = false;
      ...
    }

    (it was more than just setting a variable to true or false, but you get the idea) ...

    so, when the dev forget the "else" statement, it of course didn't work the way it was intended/designed to ... if condition_A was true, optionA was set to true but subsequently set back to false ... but, it "works as coded"

    somebody else had mentioned something to the effect that sometimes a design is faulty and the implementation is correct ... that is true ... but that's not justification to close a trouble ticket with "works as coded" ... the correct response would be to have the trouble ticket changed from "the code doesn't meet specs/requirements" to "the specs/requirements are faulty and need addressed" (and thus reassigned) ...

    Without knowing about the code, I read the exchange this way:

    Dev: I'm closing this ticket
    You: But the code doesn't follow the design doc!
    Dev: That doesn't matter if it meets the requirements.

    Under that reading, and assuming the software is not mission-critical, the developer is absolutely right. It's not about designs being "faulty." It's about recognizing that, due to schedules and blindsides, developers don't always have the luxury of following the design doc to the letter. That's a poor excuse not to fix a missing else, but it does explain a lot of things that end up in shipping code. Show me a programmer who's never had to live with ugly code, and I'll show you a college student.

  • Anonymous (unregistered) in reply to John Hensley
    John Hensley:

    Without knowing about the code, I read the exchange this way:

    Dev: I'm closing this ticket
    You: But the code doesn't follow the design doc!
    Dev: That doesn't matter if it meets the requirements.

    Under that reading, and assuming the software is not mission-critical, the developer is absolutely right. It's not about designs being "faulty." It's about recognizing that, due to schedules and blindsides, developers don't always have the luxury of following the design doc to the letter. That's a poor excuse not to fix a missing else, but it does explain a lot of things that end up in shipping code. Show me a programmer who's never had to live with ugly code, and I'll show you a college student.


    yeah, I can understand how it was read different
    I tried to keep the original post minimal though ...
    I also understand the perspectives from dev (I am a dev too)

    The biggest WTF at that company though was the company's strict adherence to PROCESS over little things like: meeting deadlines, quality design/implementation/etc., or even reduce overhead costs.

    As an example, we had a feature miss deadline once (costing the company $millions) because a serious bug was discovered which required a bit of redesign at the requirements level, but the dev team wasn't allowed to start the implementation of the then-known design until requirements phase was complete ... *sigh*

Leave a comment on “Stop Reviewing the Code”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article