If I need to discuss something with a colleague and (s)he's sitting right there, I have to hit myself not to just blurt out loud what I wanted to say. A lot of times the mouth is quicker than the mind and I'll upset ppl. If OTOH we're sitting in separate offices I have to physically leave my office and enter my colleague's office to do that. A lot of the times I realize that I can figure out a solution by myself by the time I reach my door. The other times the discussion takes place in a private office and no one else is disturbed.
Let's introduce a policy: Talking even one word in such a public space (except for emergencies like fire hazzards etc.) costs 100$ each time. This way everybody should learn the lesson very soon.
We can also implement a policy that any software developer who writes a bug gets a $100 fine, that should teach them!
I wonder why no one has thought of this before? Hey HN, I have solved the problem with bugs in software! If you implement my solution there will be no more bugs! Ever! Now give me my Nobel Prize!
I seriously doubt that this would help to reduce the bug rate. But let us for now assume that it really did reduce the error rate.
First: What does one consider as a bug? The interface of typical functions is not well-specified. So let's create a function that creates a C# IList from passed parameters. Now consider that IList<T>.Count returns an int. What is supposed to happen if the list that is generated will have more than Int.MaxValue elements? Is the not-consideration of this a bug in the code or something that a caller of this function should never do?
So one consequence would be that we additionally define a contract of pre and post invariants for each function so that it becomes clear whether something is a bug in the function or a bug of the user of the function.
Of course we would have to do the same for all libraries that we use, implying that we can hardly use any available library (at least not until libraries also begin to implement such a strict policy). So a lot more code to write.
I don't want to begin to talk about bugs in parts of the stack one has no control over (e.g. OS, compiler, browser) and code whose whole purpose is to circumvent these bugs one has no control over (how do you even detect in this kind of code parts what is to be considered as a "100$ bug"?).
Nearly every programmer will say: "if I really have to deliver such a low error rate because otherwise I lose money, at least I have to be allowed to use methods that enable generation of code with an error rate that is so low that it is affordable for me to submit to a 100$ per bug policy". So at least being allowed to create a giant test suite for the code or even better being allowed to use mathematical methods of formal verification.
So we get code with indeed an extraordinarily low bug rate - but on a pace that is so slow that few companies can afford it.
TLDR: Things that one would have to do to even implement such a policy would increase the quality of the code a lot. I personally believe if these were implemented a 100$ per bug policy would not be necessary anymore because the bug rate becomes so small. On the other hand these actions would increase the development time by a lot - thus increase the cost by a lot. So except for, say, software from avionics, medical devices or military this is probably not affordable.
I agree, but this way readers of HN get something that they can refer to if some manager gets an idea like:
- We can also implement a policy that any software developer who writes a bug gets a $100 fine, that should teach them!
- Let's measure how many bugs each programmer produces so that we can give bonuses for programmers that produce few bugs