This sounds absolutely nutty. It is expending a great deal of effort for very questionable benefit, and the practice seems based on some faulty premises:
That QA won't work hard unless they know they are being tested every day (which cannot be good for morale)
That there are not enough unintentionally introduced bugs in the software for QA to find
That QA's ...
25000 errors basically means "don't touch that". Change it back. Create a new class that has the desired interface and slowly move the consumers of the class to the new one. Depending on the language, you can mark the old class as deprecated, which may cause all sorts of compiler warnings, but won't actually break your build.
Unfortunately these things ...
Well, based on what I've learned:
It's not a school nor job interview;
The testers are not children;
It's not a game;
It wastes company's money.
The QA are not there only to find bugs but also to worry about how intuitive the system is, what is the learning curve for the user, usability, and accessibility in general. For example: "Is the system ugly?", "Is ...
What looks like guessing from the outside often turns out to be what I call "debugging in your mind". In a way, this is similar to grandmasters' ability to play chess without looking at a chess board.
It is by far the most efficient debugging technique I know, because it does not require a debugger at all. Your brain explores multiple code paths at the same ...
From the tester's point of view: "So they will test hard, because they know there are bugs present and not finding them might be considered as their incompetence." Basically the devs are booby-trapping the code. Few people like doing work which is ultimately pointless (because the bugs are known in advance) but which still affect how they are ...
By using a debugger. For the most part, this is also what an IDE does behind the scenes -- it just wraps the experience in a GUI.
On Unix, one of the most commonly used debuggers is GNU gdb, which has largely supplanted the earlier Unix debuggers such as dbx.
To get an idea of what debugging looks like / feels like from the command line, you can look at ...
Many answers have questioned your boss' methods/tactics/metrics/etc. But that is beside the point. Maybe you ARE slow. Every room of developpers has to have ONE that's slower than the rest, right? (That's just straight set-theory.) So let's assume that's you. The answer is, WHY are you slow? (Clearly that is the question you have to answer before you can ...
Divide and conquer with refactorings
Often, breaking up the change that you need to do into smaller steps can help because you can then perform most of the smaller steps in a way that doesn't break the software at all. Refactoring tools help a lot with such tasks.
First, identify the smallest possible changes (in terms of logical changes, not in ...
For ad-hoc checks, just use a standard hexdump and learn to eyeball it.
If you want to tool up for a proper investigation, I usually write a separate decoder in something like Python - ideally this will be driven directly from a message spec document or IDL, and be as automated as possible (so there's no chance of manually introducing the same bug in both ...
Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?
You should give it your best effort. I know that sometimes there are conditions and environments that are so complex they can't be reproduced exactly, but you should certainly try if you can.
If you never reproduced the bug and saw it for yourself, how can ...
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,
Your boss may be correct: you may be "underperforming" (more on that in a minute). But it may not be just your level of competence that's to blame. I don't think it would be a reach to suggest forces outside your control are causing you stress, which is having a negative effect on your performance.
Let's have a look at a few of the reasons your boss may now ...
You want to look at a logging framework, and maybe at a logging facade framework.
There are multiple logging frameworks out there, often with overlapping functionalities, so much so that over time many evolved to rely on a common API, or have come to be used through a facade framework to abstract their use and allow them to be swapped in place if needed.
I want to be clear that this answer is only talking about the concept of testing your QA process, and I'm not defending the specific methodology portrayed in the question.
There is a valid reason to check if your testing/checking is actually working. Let me give you an example from manufacturing, but the principle is the same.
It's typical ...
A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.
Is there some kind of cultivatable behaviour [...] that can help me at least reduce such kind of mistake
Absolutely, it is called four-eyes-principle.
If you had you shown your crontab entry to a second person (a person knowing cron, of course), chances are high the mistake would have been avoided.
In programming, when it comes to this, people mostly ...
Introducing explaining variables is a well-known refactoring which can sometimes help to make complicated expressions better readable. However, in the shown case,
the additional variable does not "explain" anything which is not clear from the surrounding method name
the statement gets even longer, so (slightly) less readable
Moreover, newer versions of ...
The more I know a code base, the less I need a debugger (but I'd still check the reported error, it is an important clue in any reasoning).
It is a fine tool to understand some dynamic behavior of small to medium complexity, but I often find out that it focus me on the details instead of the bigger picture. And after a while, that's where the problems are: ...
Some work environments are unworkable. I've seen environments in which no one could survive (save for those who were in at the beginning) because so much was undocumented and questions were so vehemently discouraged.
You really need to be honest with yourself regarding the expectations and the resources provided to help you to meet them. The problem may not ...
Given the facts that:
a) There is no impact on the final code as the compiler optimises the variable away.
b) Having it separate enhances debugging capability.
I've personally come to the conclusion that's it's a good practice to separate them 99% of the time.
There are no material disadvantages to doing it this way. The argument that it bloats code is a ...
I really have a hard time seeing where I went wrong
The major mistake was that you reinvented the wheel. Instead of using default mecanisms for logging, you invented your own, which displayed the information within the page. A logging framework would rather store logs in log files, letting you to consult those logs later by SSHing to the server.
As for the ...
It affects the efficiency in a very good way.
I feel that it's used too seldom by developers.
Not only is it good for debugging but it can also give you an insight in profiling.
For example when line stepping you can feel "ahh" this line took a little too long time to execute and you get a feeling for where the bottlenecks in your app are.
I can see a DOS programmer fiddling away and crashing the entire OS when he made a mistake.
Yeah, that's pretty much what happened. On most systems that had memory maps, location 0 was marked invalid, so that null pointers could be easily detected, because that was the most common case. But there were lots of other cases, and they caused havoc.
At the ...
Clarify your task with your boss to help him to understand the problem and your needs as a professional software developer.
If you are part of a team, look for the lead developer and ask him for advice.
They may not be bad programmers, but they are probably terribly inefficient troubleshooters.
I tend to follow the advice from Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (David Agans), and this one falls squarely under the guidance of "Quit thinking and look"
I used a debugger for several years while I was writing graphics drivers. I had a second computer that ran the debugger against the first one (because the screen in the primary computer wouldn't work when the graphics driver was broken). It was critical to be able to stop the code and step to the point where I hung the hardware so I'd know what was ...
How do they intend to verify that the bug in question was fixed? Do they want to ship untested code to the user and let them figure it out? Any test setup that was never shown to reproduce the error can't be relied upon to show absence of the error. You certainly don't need to reproduce the entire client environment, but you do need enough to reproduce ...
No, not at all !
Abstractions and good practices can of course reduce the risks of errors. For example:
language abstractions let the compiler generate code, that you would have to write yourself otherwise. For example, the C++ object model ensures that object constructed are destroyed as they supposed to be, without extra care on your shoulders;
Debugging eats up time since you are executing code a billion times slower than you would in a unit test. Often there is a better tool for the job: microbenchmarks, performance profilers, unit tests, logging, or just reading the code. With a suite of unit tests you can execute dozens of code paths in milliseconds, which would take hours in a debugger.
I think you are misrepresenting the message of the "Modern C++ in Embedded Systems" video. The point is that there are people in the embedded world that write code and then test it by running the code in the debugger to verify that it does what they think it does. He argues that a better alternative is to use abstractions so that the compiler can verify that ...