2 improved formatting and flow.
source | link

I agree totally with the answers above as to why this is bad for motivation and just generally awful people management. However, there are probably sound technical reasons for not doing this as well:

Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working code to make sure that those bugs aren't shipped with the end product.

I agree totally with the answers above as to why this is bad for motivation and just generally awful people management, but as well as that, based on the first statement, you never actually test your intended production code in these two passes.

I would also note that you vastly increase the likelihood of accidentally including an 'intentional' bug into your released production code when trying to rush through a change for a customer.


Additionally I would imagine that this just trains your testers to think like your developers (i.e. how would Tom add a bug here) which probably makes them less likely to find the bugs that Tom hasn't thought about.

  1. Based on the first statement, you never actually test your intended production code in these two passes.

  2. I would imagine you vastly increase the likelihood of accidentally including an 'intentional' bug into your released production code when trying to rush through a change for a customer. Might cause a few red cheeks at some point.

  3. I would imagine that this just trains your testers to think like your developers (i.e. how would Tom add a bug here) which probably makes them less likely to find the bugs that Tom hasn't thought about.

Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working code to make sure that those bugs aren't shipped with the end product.

I agree totally with the answers above as to why this is bad for motivation and just generally awful people management, but as well as that, based on the first statement, you never actually test your intended production code in these two passes.

I would also note that you vastly increase the likelihood of accidentally including an 'intentional' bug into your released production code when trying to rush through a change for a customer.


Additionally I would imagine that this just trains your testers to think like your developers (i.e. how would Tom add a bug here) which probably makes them less likely to find the bugs that Tom hasn't thought about.

I agree totally with the answers above as to why this is bad for motivation and just generally awful people management. However, there are probably sound technical reasons for not doing this as well:

Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working code to make sure that those bugs aren't shipped with the end product.

  1. Based on the first statement, you never actually test your intended production code in these two passes.

  2. I would imagine you vastly increase the likelihood of accidentally including an 'intentional' bug into your released production code when trying to rush through a change for a customer. Might cause a few red cheeks at some point.

  3. I would imagine that this just trains your testers to think like your developers (i.e. how would Tom add a bug here) which probably makes them less likely to find the bugs that Tom hasn't thought about.

1
source | link

Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working code to make sure that those bugs aren't shipped with the end product.

I agree totally with the answers above as to why this is bad for motivation and just generally awful people management, but as well as that, based on the first statement, you never actually test your intended production code in these two passes.

I would also note that you vastly increase the likelihood of accidentally including an 'intentional' bug into your released production code when trying to rush through a change for a customer.


Additionally I would imagine that this just trains your testers to think like your developers (i.e. how would Tom add a bug here) which probably makes them less likely to find the bugs that Tom hasn't thought about.