Comment On Stop Reviewing the Code

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.

OH MY GOD. It's just..... What the.... And they..... bah!

I really hope no one is using that software....

Ya know.... something tells me that this isn't to uncommon in today's world...

So, where's Jimm working at now?

P.S. Good choice of non-code WTF.

For me the phrase was, "You're spending too much time down in the weeds looking at code.  I need you to operate at a higher level and manage the (non-technical, end-user) business side people doing the actual testing."

A few extra rows in a database is not nearly as big a problem as a few rows missing...

... and yes, that's a joke.

...wow...

reminds me of when i pointed out the sql injection vulnerability in my company's website.

GoatCheez:

Ya know.... something tells me that this isn't to uncommon in today's world...

A friend of a friend simply got fired from her QA manager position for similar 'issues'.
The QA people who took over found less problems with the app.

I'd say WTF, but my previous job was worse.
As a software QA, it was my job to find the issues before the customer did right?

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.

Anonymous:

Me: "... but it doesn't work as designed."
Dev: "So? It works as coded and that's all that matters."

I'll take "Statements that are Always True" for $500, Alex.

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."

Works as CODED?  WTF does that mean?!

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.

This is by far the very best response in the blog in a very long time. Kudos!

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."

If I hadn't been the only QA guy left by the time they actually started releasing code, I'd swear this was someone I worked with. Because I had the exact same conversation several times.

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."

 

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

Anonymous:

I'd say WTF, but my previous job was worse.
As a software QA, it was my job to find the issues before the customer did right?

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.

Lovely...  There are only two possibilities in his world: "Works as coded, so it is not a problem." - and - "Doesn't work as coded, so it's a compiler error."

Either way, why even have trouble tickets?

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

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.

I worked for a company once where cosmetic defects were top priority
and function defects were much lower. The rationale for this was that
the end user would certainly see a word misspelled, but perhaps they
wouldn't notice a fragmented financial transaction.



But it really didn't matter. *None* of the bugs that we reported got fixed.



Funny enough one of the smarter guys I ever worked with was a "Jim".



Funny enough one of the less smart guys I ever worked with was our boss.

Anonymous:

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."

Works as CODED?  WTF does that mean?!

It's polite-speak for "You can kiss my shiny metal ass."

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

On the 10F202 microprocessor, the manufacturer moved the location of the configuration word between the initial datasheet and final manufacturing. The compiler manufacturer and the progammer box manufacturer both used the old specs. What happened was that the configuration word got written to the wrong location in memory. The operation was therefore not what was programmed.

On the 16F88 microprocessor, an older version of the compiler didn't handle the analog ports correctly. When the compiler was updated, the new handling caused any read on the pins to set all the pins on the port to go low. Again, not as programmed.

R.Flowers:

A few extra rows in a database is not nearly as big a problem as a few rows missing...

... and yes, that's a joke.

I almost took umbrage until I saw the joke part.

Does this sort of thing happen a lot? ;)

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...

Anonymous:

Works as CODED?  WTF does that mean?!

I could also imagine a time where a developer correctly used an external API, and that API failed.  So the app wouldn't behave as it was coded.

I got this once:

Boss: How's the project going?

Me: We completed <i>m</i> issues, and we now have <i>n</i> items in the list that need to be addressed.

Boss: <i>N!</i>.  That's more than last time!.  You aren't making any progress...

 

oh well...

Saarus:

R.Flowers:

A few extra rows in a database is not nearly as big a problem as a few rows missing...

... and yes, that's a joke.

I almost took umbrage until I saw the joke part.

Does this sort of thing happen a lot? ;)

I don't care how much umbrage you take, as long as you leave some for the rest of us.

Anonymous:

I worked for a company once where cosmetic defects were top priority and function defects were much lower. The rationale for this was that the end user would certainly see a word misspelled, but perhaps they
wouldn't notice a fragmented financial transaction.

Funnily enough I've encountered the opposite situation - fixing cosmetic defects was pretty nearly forbidden since they were unimportant to the function and therefore any time spent on them was by definition wasted. Not quite as serious as your situation, but still ...

Alex Papadimoulis:

in You see, Jimm's manager, in addition to being a model leader, was also a cost-conscious one. He realized how completely unnecessary project managers, architects, designers, developers, and testers were for the phase of the project,

That's life in a small shop.  I've worked in the biggest of big and the smallest of small (i.e. me and a non-technical boss).  In the big shops everyone has to do their independant job as well as possible, but in the small shops you have to do as many jobs well as possible.  In other words, the personel might vary but the functionality must still exist.  You just got to divide your time up amongst the different duties effectively.

So the management might want to check out this listing and do some further research:

http://en.wikipedia.org/wiki/Software_development_life_cycle

Nice picture of the chump!

"What we have here is a failure to communicate"

Jimm takes alot of the blame. He failed to articulate WHY this class of bug was so important. The write-up made it clear - "half state data-changes", but is that an after thought? Inconsistent Data is a show stopper. Period. If Jimm couldnt get that message across then he shouldnt be in Testing. Add to that an incompetent manager, and you get a corporate level WTF.

I wonder if firefox followed this lead.  I use it, love it, but what the *&%# happened to my bookmarks with this last patch.

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."

If I hadn't been the only QA guy left by the time they actually started releasing code, I'd swear this was someone I worked with. Because I had the exact same conversation several times.

Yup, I've been though that , too..
Well, this is a standard  dialogue and there's nothing we can do...

Actually, I think Jimm probably "griped," not "gripped," although it's possible he "gripped," but the wrong thing.  He should have been gripping his manager's neck, tightly and continually, until consciousness waned.

[ED: Fixed Typo]

Anonymous:

Works as CODED?  WTF does that mean?!

It compiled.  Ship it!

No longer with the same company. I tried to rationalize and supress my views for few months, but finally decided to leave the boat.

BTW the software is used in transactions worth few million dollars a day.

Anonymous:

BTW the software is used in transactions worth few million dollars a day.

We never worked at the same company, did we?  In Pittsford NY?

Anonymous:

No longer with the same company. I tried to rationalize and supress my views for few months, but finally decided to leave the boat.

BTW the software is used in transactions worth few million dollars a day.

Good thing you got out of there! I really wish people were allowed to say who used what. I would certainly stay away from any services this company provides. I think it'd be a good thing too because it would force companies to hire competent programmers for fear of their bad code bringing them bad publicity and lower sales.

It's obvious you idiots, release cycles are NOT the place to find 'issues' they are much easier to find in production in fact we don't even have to pay people to do it our customers will do it and then pay us more money to fix them, it's all part fo the business plan.

Let's listen to our industry's name being flushed down the toilet by all the cowboy companies out there. Yee ha!!!

Anonymous:

I got this once:

Boss: How's the project going?

Me: We completed <i>m</i> issues, and we now have <i>n</i> items in the list that need to be addressed.

Boss: <i>N!</i>.  That's more than last time!.  You aren't making any progress...

 

oh well...

Do you work at my office??  :)

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.

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

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.

This job was for one of the biggest global $$$$$ firm. Problem did not  lie in the budget, but in the fact that the program manager just knew that the decisions made by anyone other than him, lead to the land of the doomed. So issues like he never trained himself in the technical area or understood technical issues, did not stop him from making architectural, design, QA decisions. In fact he liked making those decisions more than the business ones because it gave him reassurance that without him the project would not survive.

First you ask the boss, "What kind of bug *is* a showstopper?" Then you can figure out how to make all bugs fit that definition...

LoL, absolutely true.

In fact, that particular company's compensation structure promoted such software morals.

As long as the manager can ship the code to production, the manager and the senior management associated with the project got hefty bonuses and promotions.  As always customers would find bugs and it really dint matter if the app worked in production. Actually, a new mission would be created to rewrite a 3 month old production app again with different vendor and a hefty budget ofcourse!! and the cosy feeling that this time things would be better keeps everyone happy.

 

I had a job like that.  I was in QA, and they were very big on rigorous documentation showing that we verified that each feature *could* work, but any actual complaints about failures were derided and mocked.  This was a product where I was once told that a failure in production could easily cost thousands of dollars.

If you clicked on a button, nothing happened (not even a visible "depress" state) until a fairly slow thread caught up with you.  If you clicked twice, many buttons would cause coredumps.  A report of this got posted in engineering with "QA hard at work" on it.

Needless, to say, it was awful code; fortran written in C++.

Anonymous:

LoL, absolutely true.

In fact, that particular company's compensation structure promoted such software morals.

As long as the manager can ship the code to production, the manager and the senior management associated with the project got hefty bonuses and promotions.  As always customers would find bugs and it really dint matter if the app worked in production. Actually, a new mission would be created to rewrite a 3 month old production app again with different vendor and a hefty budget ofcourse!! and the cosy feeling that this time things would be better keeps everyone happy.

I feel your pain. I worked in a place where the only relevant thing was the Almighty Date. Of course, the developers were supposed to write perfect code the first time, with perpetually changing (possibly incorrect/incomplete) specs from the sales-chimps - because it was our job to know what was needed. No architectural design was required because it was simple: just a button here, a text box there, n-tier distributed asynchronous multi-threading everywhere. I finally resigned, with a smile and a laugh - they didn't get why. They ultimately hired several consultants to replace me when they finally realized that maybe I had been pushing really hard to keep up, and was just tired of stupidity. They called me a couple of times asking me to come back. I stopped answering their calls.

Welcome to neill.net

Sounds like my old job. My non-technical manager had to poke his head into everything--requirements, design, QA, architecture, code reviews--and if he had a sudden revelation, you'd better watch out. See, there was no arguing with him. Oh sure, he would be happy to debate ideas, but since he had no technical background, it was like slamming my head into a brick wall over and over and over. Did we waste months of effort because he figured he alone understood the customer's requirements? Oh, no biggie! Critical security hole that opens a back door to the whole system? Well, no one will find that--ship it! Yay, we made our ship date! Good job, guys!

Most tragicomic thing there was when I was penalized on my performance review for greatly increasing transaction throughput, which we sorely needed to do. He rationalized this by saying "If you improved it, then that means it was badly written the first time." He could rationalize anything. Calm and serene, like a Zen Buddhist.

I would like to clarify my comment above. I mentioned asynchronous multi-threading, which is kind of redundant. The reason is that at this particular think-tank, some cerebral-type coder came up with the concept of synchronized-threading. What is that, you might ask? Imagine if you will, in Java-parlance, a thread on which requests arrive. The listener of this request-thread fires off a notifyAll to a pool of worker threads, upon which one of the inactive threads will be awakened to process the aforementioned request. The worker thread is approximately 5K LOC, but it directly interacts with a highly serialized process in another system, and so every other block is wrapped with synchronized. In this case, it completely defeated the purpose of using threads.

Hence: synchronized threading. Hence, my auto-pilot reference to asynchronized threading .

Will it never go away? Please, make it stop!

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. 

LRB:

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. 

You could have gone back to them as a consultant, and brought in SDLC, in concert with Sarbanes Oxley - makes for one heck of a lot of requirements paperwork. That would keep any paper-pusher-wannabe happy!

Anonymous:

I'd say WTF, but my previous job was worse.
As a software QA, it was my job to find the issues before the customer did right?

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.

Maybe it was a subtle hint from the developer that you should really just bend over and take it from management like a good little yes man.

Trainwrecks are much cooler to watch when you're not emotionally attached.

snoofle:

LRB:

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. 

You could have gone back to them as a consultant, and brought in SDLC, in concert with Sarbanes Oxley - makes for one heck of a lot of requirements paperwork. That would keep any paper-pusher-wannabe happy!

This was the late 90's, so no Sarbanes Oxley.  I was a consultant, and did try and bring in SDLC, but no buyers.  Just wasn't a situation where I wanted to work.  There were plenty more WTF's at this place.

Maybe it was a subtle hint from the developer that you should really
just bend over and take it from management like a good little yes man.

In this case, it was simply the Dev hinting that QA didn't know how to do its job; how else could QA believe there was a bug in his code?