As to fear of bugs: I don't avoid writing bugs because they scare me; they do not. They always happen, just like taxes. I only want to avoid bugs because they annoy the heck out of me. So, I trade time and effort for not getting annoyed too often.
Look at that this way. Once you have written software, it will have bugs. Here, there ... You don't know where they are and therefore you cannot fix it. Your software is buggy and crappy. Then, you encounter a bug. Either you find it yourself, or QA engineer filed a report, or user filed a support ticket. This is good luck for you. This gives you an opportunity to work on it and fix it. This will make your software better, and your software will eventually becomes clean and reliable. If you didn't find the bug, the software would remain crappy.
How can you possibly look at this very positive event as if someone is throwing dog shit at you?
I realized I left out a crucial word there:
writing.
The way I usually encounter a bug is when they silently garble my data (which I consider similar to having a nice big streak of poo on your back), or a process produces unexpected and useless results. There is usually some pain involved – not just "what now?", but the "hmm, I cannot pinpoint any logical errors in this chain".
Whenever I get a bug report, or a colleague pointing out a typo, thinko, or even a severe misunderstanding (and that last category requires
verifiable proof, not just someone quoting the standard as if it was the holy bible; me being a dirty pagan after all),
I get ecstatic.
A good bug report, one with a verifiable test case, and showing why a specific behaviour is desired, is in my book worth a very nice Thank You, perhaps a cuppa or a beer depending on the environment; and I am definitely in the habit of telling anyone who has produced a good one for me to fix a bug with, that if they don't get a response quick-ish and they have more of these, to ping me.
I do often go bug-hunting in all sorts of projects. (In my mind, "avoiding bugs" includes "make bug-hunting raids now and then"; it just doesn't translate well to the English I type out. Apologies.) If a friend or acquintance has a problem with a project I'm unfamiliar with, but which uses tools I'm comfortable with (as in, do not need to set up completely new development environments, very specific versions of nonstandard libraries, and such), but can either browse the sources online or pull a git, I *often* help.
(There are members here who've contacted me via PM that I've done exactly this for/with/to. English! In exchange, I only ask them to pass it forwards. Since I haven't been active at StackExchange, direct emails from there have dropped down to a trickle, less than one a week.)
I guess my attitude is much better described as
"does not ignore known bugs, likes to squash them, and keep their population down".
If you cannot tell where the bugs are after you write the software, you certainly cannot tell where they are before you write the software. Of 100 lines you write, may be one or two will have bugs, may be even none. If you look at every line as if it already contained a bug (which it most likely doesn't), and try to figure what the bug can possibly be, and try to fix it even before your write that line, you make your job needlessly hard. If it's not broken, don't fix it.
Yes, and no. If I have no reason to suspect a code does not behave as it is supposed to, I don't worry about it.
The suspiciousness when reading code basically boils down to looking at the code critically and asking oneself,
Does this code do what it is supposed to do? (split into two sub-questions,
Did the original programmer choose a suitable algorithm or approach? and
Does the code do what the original programmer intended?) and
Are there any expressions here I should be taking a more careful look at?It is not the same thing as thinking there might be bugs. It's more like a structural engineer walking through a worksite, and looking at the girders and walls to see if anything seems fishy; not just say cracks in the concrete, but whether the concrete has eroded in places already indicating the mix was incorrect in the first place.
(A typical such "erosion", in my opinion, is a program that takes user parameters, but never checks them (even whether they were parsed correctly or not), and just assumes that they should be, since we haven't crashed yet. It itself is not necessarily an error, but it indicates that a closer look may be warranted. Even I use
sscanf() to parse user input sometimes, even though it doesn't properly check for all possible errors (numerical overflows in particular); it's just .. hmm... an indication of the sort of neighborhood you are in. If it is an industrial hall used to store vehicles, it may not need *walls* at all, wallpaper and hardwood floors even less.)
This, too, is a skill that can be cultivated, and does not need any special "aptitude" for it. I do believe most programmers concentrate too much on *emitting* code, and not enough on *examining* already existing code. With the sheer amount of existing open source code in public source code repositories, one really only needs some sort of a yardstick to pick some "good ones" and some "bad ones", and start reading, comparing, and trying to understand; it only takes time and effort.
I think the biggest software system defects aren't implementation bugs but requirements / specification / documentation bugs.
Yes, I think I have to agree. I do feel they occur in a slightly different context, though: instead of silently garbling data, they just refuse to work in an useful manner, or forbid actions or expressions that the user needs to perform their tasks. (Lots of compiler features in this class! Yet, I still use C and C++.)
One of the issues I do have, is that people assume terms have a specific meaning without checking. Worse, if they insist, without trying to find any agreement on the uses. (And, I do claim, it is the uses that define the meaning, not any particular claims of their meanings, no matter how "authoritative". Consider
Albert Einstein and the cosmological constant.)
If you stick to the compiler or standard definitions, your understanding will be bracketed, limited and defined, by that standard; and there really isn't any reason to believe any committees get the definitions right. A human mind has to be nimble, and think about the unstated assumptions even they themselves are making, be ready to shift context whenever such a shift is warranted, and just deal with it all.
In physics, outside classical mechanics, even the term
mass is problematic, because one cannot be sure if it refers to the invariant or rest mass, or relativistic mass as the analog or extension of classical mass with Lorenz factor "correction". Electrons do not "orbit", they have "orbitals"; but in many languages the two map to the same words, with much confusion. In mathematics, you need to tell what each of your variables represent, and if for example you use \$\vec{v}\$ for a generic vector, but \$\hat{v}\$ for an unit vector (like I often do). In linear algebra, when dealing with matrices and vectors, if you use the \$\vec{v} = (x, y, z)\$ notation for vectors in the text (instead of \$\vec{v} = \left[ \begin{matrix} x & y & z \end{matrix} \right]\$ or \$\vec{v} = \left[ \begin{matrix} x & y & z \end{matrix} \right]^T\$ , you also need to remember to tell whether your vectors are row or column vectors, because one of \$\mathbf{M}\vec{v}\$ and \$\vec{v}\mathbf{M}\$ yields a vector and the other a matrix, and whether the vectors are row or column vectors, determines which.
I seriously wish that more people start realizing that the counterquestion,
"What do you mean by Z
, exactly?" in science and engineering is completely different to the social accusation it tends to nowadays be in "polite society". In science and engineering, it is an expression of interest in the subject and mutual discourse, and a request for clarification without any negative connotations. It
must be, because any other interpretation robs us of one of the core tools; that all-important one that makes peer review so valued and respected. I myself have had to learn to make sure my face expresses both interest and deep thought so in face-to-face the question isn't misunderstood, which is kinda silly and unnecessary waste of the meager efforts my thinking fat is capable of stretching to.
These are just simple human mistakes - something misspelled, misjudged, or misunderstood. You cannot prevent such mistake from happening. You can only fix them afterwards.
I'm not sure I even think of them as proper bugs anymore; they're so common and easy to fix. I myself like to sleep over an initial implementation, then review it the next day, because those always occur – like taxes! – and I consider it just part of my development workflow, not "bug hunting" per se.
I even do the same to my posts. I do preview, but after posting, I read it through once. Then, I do something else, and if I see any responses, I first re-read my own to see if anything needs fixing. Then I read the responses, and if I see a discrepancy, I re-read my own again to see if it is easily read in a different manner I intended. English is a lot of work for me, but I am a
fast reader. (And I don't just glance; the speed does not affect my understanding, I don't understand a bit more even if I read slower. When I read carefully, I consider the ways each paragraph can be understood; that takes considerably more time.)
Home
Help
Search
Login
Register
