Everything Breaks, All the Time.
jeff-vogel.blogspot.com
Everything Breaks, All the Time.
1–10 of 16 posts
Re: Everything Breaks, All the Time.
#2This fact drives me insane. It's theoretically possible to write a perfect piece of software that can never fall down, break, blow up, etc. But it's actually pretty much impossible in practice unless you have either near unlimited resources (NASA in the 60's), but even with that you still might fail (Microsoft).
Re: Everything Breaks, All the Time.
#3Only checking for a bug reminds me of the Intel bug that they claimed would hardly ever happen, but turned out to happen a LOT.
I don't ignore bugs. I follow the same first step, and send the standard list of things to try like reinstalling, rebooting, etc. But if they still have it, I always look into it. Almost every time it's been a real bug. Some were really hard to track down, but would have caused a lot of grief later. I was always glad I did it.
Re: Everything Breaks, All the Time.
#4My biz partner has a GPS system from garmin. He lives in the central time zone, but works in the eastern time zone. Any time we use the GPS it will always add an hour to our trip when we are in EST.
Programmers aren't perfect. Practice makes permanents.
Re: Everything Breaks, All the Time.
#5I dont get this, its so often a bug, and so many people dont report bugs, this strategy of telling people to reboot or reinstall or redownload just perpetuates these voodoo-style fixes.
Im not saying fix everything always immediately, but dont write people off as victims of cosmic rays just because you can't repro in 30 seconds or dont see the bug where youd expect in the code.
Re: Everything Breaks, All the Time.
#6Only checking for a bug reminds me of the Intel bug that they claimed would hardly ever happen, but turned out to happen a LOT. I don't ignore bugs. I follow the same first step, and send the standard list of things to try like reinstalling, rebooting, etc. But if they still have it, I always look into it. Almost every time it's been a real bug. Some were really hard to track down, but would have caused a lot of grie…
Have you encountered a hardware defect yet?
If/when you do, it represents a lot of technically dead time that was spent looking at code. I'm not saying either premise is right but I can appreciate his philosophy here.
For the record, I killed four weeks digging through code and running tests and it turned out that temperatures in winter coupled with some bad soldering was the cause of the issue. D:
Re: Everything Breaks, All the Time.
#7Only checking for a bug reminds me of the Intel bug that they claimed would hardly ever happen, but turned out to happen a LOT. I don't ignore bugs. I follow the same first step, and send the standard list of things to try like reinstalling, rebooting, etc. But if they still have it, I always look into it. Almost every time it's been a real bug. Some were really hard to track down, but would have caused a lot of grie…
Have you encountered a hardware defect yet? If/when you do, it represents a lot of technically dead time that was spent looking at code. I'm not saying either premise is right but I can appreciate his philosophy here. For the record, I killed four weeks digging through code and running tests and it turned out that temperatures in winter coupled with some bad soldering was the cause of the issue. D:
Yes, you have to track them down, yes it takes forever for the hard ones. But most of the time it Isn't hardware, most of the time it my own bug and I can fix it.
It definitely takes some experience to be good at debugging. I guess that's why all the emphasis on development environments these days, where the hard stuff is being debugged by someone else and I can work on my app-level stuff in peace.
Re: Everything Breaks, All the Time.
#8My biz partner has a GPS system from garmin. He lives in the central time zone, but works in the eastern time zone. Any time we use the GPS it will always add an hour to our trip when we are in EST. Programmers aren't perfect. Practice makes permanents.
Ha! And my sister went to Egypt and looked up the gps distance to home (Iowa): 8000 miles. Off by 50%. Why? The programmer was doing cartesian distance instead of great-circle. So yes, if she drilled a tunnel through the Earth's core, it was only 8000 miles. :)
Re: Everything Breaks, All the Time.
#9This guy is wrong, plain and simple. Unforeseeable bit-copying errors caused by cosmic rays and similar circumstances, which do exist, probably account for less than a one out of every billion actual bugs/crashes experienced out there. When a bit is toggled by a cosmic ray in memory, if it hits program memory, it will with a significant frequency crash your program.
Most bugs you experience daily (Word or your favorite game/appp crashing, etc...) are caused by actual software errors in overly complex systems with many dependencies. Multithreaded-coding errors can often account for many of those, but not only, complex system with many layers and complex dependencies can often hide obscure behaviors that can cause crashes in a given machine if, for example, you have a weird combination of disk drivers, file system code, and an antivirus hooking and acting on every filesystem read or write.
When, for example, a Word plug-in makes a call to Word's object model, this goes through easily 10 software layers until it reaches its target, some of these layers being configured via the flaky Windows registry, others going through jumps from VM-based to native code using weird "marshalling" techniques, etc... in these cases, you may encounter buggy behavior in any one of the 10 layers, or in a combination of two of them, even if it seems like you are just incrementing a simple counter.
Most of the time, though, bugs are caused by the app's own code (your own code): careless code, dangerous practices, lack of solid control-flow design, etc... if you write really good code, it's unlikely you will have many support issues. Only if you are working in some problem-prone area: plug-ins to other complex, often poorly-designed products, code pushing graphics drivers to the max, etc... where you get into "complex system" behavior.
Even if you use multithreading, if you control all the code, you can write very solid code. If your multithreaded code is perfect, it won't crash. Although it can uncover bugs in third-party libraries, etc... which is why I tend to write only "worker threads" with no third-party dependency if multithreading is required.
And I think it's very dangerous to warn novice programmers to think that the bug is probably somewhere else.
Re: Everything Breaks, All the Time.
#10Only checking for a bug reminds me of the Intel bug that they claimed would hardly ever happen, but turned out to happen a LOT. I don't ignore bugs. I follow the same first step, and send the standard list of things to try like reinstalling, rebooting, etc. But if they still have it, I always look into it. Almost every time it's been a real bug. Some were really hard to track down, but would have caused a lot of grie…
Have you encountered a hardware defect yet? If/when you do, it represents a lot of technically dead time that was spent looking at code. I'm not saying either premise is right but I can appreciate his philosophy here. For the record, I killed four weeks digging through code and running tests and it turned out that temperatures in winter coupled with some bad soldering was the cause of the issue. D:
I have definitely encountered bugs that I could not track down, which very well might have been a hardware problem. I was eventually forced to give up on it. (And I've gotten better at giving up earlier when something is going to be impossible to find.)
But I have never said, 'I won't look into a bug until multiple people have it.'