implies that ItWorks
sometimes, vs WontWork
. Sometimes I hear ItsNotWorking
, meaning it did, but not now.
It can also mean, when I put in what the computer expects, ItWorks
, but when I give the computer a surprise, ItDoesntWork
Hearing the phrase "it doesn't work" in a certain context makes me cringe. To me, it shows a lack of understanding and commitment to the project.
Here is an example of what I mean:
Bug reporter : "It doesn't work."
Developer : "What doesn't work."
Bug reporter : "I don't know... I'm having the strangest problems. Sometimes
it works, other times it just doesn't return, and other times
it just plain crashes."
Developer : "Well, lemme know when you can tell me what doesn't work."
Bug reporter : "okay, the bug report will remain open."
-- Later that day --
Developer : "So did you figure out what the problem was?"
Bug reporter : "Well... I went in and tried a few things now it works."
Developer : "So what was it?"
Bug reporter : "I'm not sure, but at least it works now."
In contrast to ItWorks
is what you often get instead of a detailed report or a testcase which illustrates what is broken. Similar to VoodooFix
as pointed out by JeffShelby
, this creates a sort of VoodooBug
, where you are never quite sure what / if the problem exists.
What can we do to try to decrease the number of times we hear "ItWorks
" and "ItDoesntWork
" in this negative context?
s result when the system becomes more complex than a human mind's ability to understand it. The solution is to alwasy simplify the system when you can no longer fully understand
it. When you catch yourself thinking hard about how a change will interact with the system, it's too complicated. -- SunirShah
All VoodooBugs are a result of this?
How do you simplify the operating system or the VM?
Can I move this to the VoodooBugs page?
You can simplify an operating system by reducing the scope of the operating system. A microkernel, for example, can fit in as little as a few kilobytes of memory (as evidenced by L4 and QNX). The microkernel is a highly modularized kernel, choosing to use IPC to implement cross-module interactions. If this is to costly time-wise, then perhaps C is an inappropriate language for writing a more monolithic kernel. In this case, you might want to consider something like Oberon, or if garbage collection overheads aren't acceptable, maybe a dialect of Oberon that uses manual memory management (e.g., Oberon-0 perhaps?). You can still use applications written in C, since the kernel exists in a fundamentally different address space anyway. This way, you get the benefits of strong
modularization, without the time-expense of message passing between modules. However, experience with various user-space tools like X Window System shows that message passing and shared memory can be optimized very closely to native API speeds (otherwise, animation and video playback could not occur via X11). It does this via batching many requests in a single RPC transaction. L4 takes this route as well, thus L4's reputation for being a very high performance microkernel.
You can create a complex system with smaller parts that are more easily understood. It's possible to lump the kernel, filesystem, graphics drivers, etc. into a single "operating system" image. But, if there are no good modular boundaries, with adequate type systems used (either Smalltalk-style strong, dynamic types or Oberon-style strong, static types) to allow the programmer to reason about the code, then there can be no understanding of the software.
A 4K Ram Trs-80 with Basic and single character variables, circa 1978, perhaps? -- DonaldNoyes
On a project I was working on recently, I was regularly given really vague bug reports -- along the lines of program "Z" doesn't work right; please fix it.
So I go look at the program, find several bugs, and fix them.
Typically, none of these bugs would turn out to be the one they were complaining about!!!
ProveIt. Well, ask them too in a nice way... :) -- ErikMeade