"Incidentally, this is one of the reasons that crunch time is a failed development methodology, as I’ve mentioned in past posts on this blog; developers get tired and start making stupid mistakes."<p>Totally. Strangely enough, Founders at Work (<a href="http://www.amazon.com/Founders-Work-Stories-Startups-Problem-Solution/dp/1430210788" rel="nofollow">http://www.amazon.com/Founders-Work-Stories-Startups-Problem...</a>) is chock full of startup founders extolling the virtues of overwork. Is this some survivorship bias or does overwork in startups really lead to shipping sooner and achieving product/market fit faster?<p>It's never been my experience that sustained overwork of software developers leads to actual, measurable productivity increases due to the "two steps forward, one step back" phenomenon. Yeah, you can ship a feature "sooner" but it'll be buggy and disappointing to the end users (probably causing them to hesitate to pay - are you really achieving product/market fit with a buggy product?)<p>We encourage every developer to find a sustainable pace (it's different for everyone) with the guidance that it's almost always less than 50 hours a week. Why is it that software companies think that overworking software developers is a net positive?
Whenever a fellow programmer or myself starts even considering that the OS, .NET-Framework, JVM etc. might be responsible for a bug, I have to smile.<p>In that moment, 2 things are almost certainly true:<p>1. The bug is in <i>your</i> code.
2. You are too tired/stressed/overfocused to see it.<p>So when I find myself in this state, I instantly stop working and go for a walk (or go home when its late enough).<p>Then, when rested, I tackle the problem again. I will find my bug, or, for the very rare case, find a way to <i>prove</i> that it really is the environment my code runs in.<p>But most importantly, I will have a sharp tool for the job.
<i>"The bug was easily fixed by upgrading the build server, but in the end we decided to leave assertions enabled even for live builds. The anticipated cost-savings in CPU utilization (or more correctly, the anticipated savings from being able to purchase fewer computers in the future) were lost due to the programming effort required to identify the bug, so we felt it better to avoid similar issues in future."</i><p>I'd like to ask: for anyone here who's ever worked on a large C++ codebase, were assertions ever actually observed to be a noticeable detriment to performance? I'm sort of naively assuming that a good branch predictor would make their impact negligible, but I ain't exactly a system programmer.
I really like the part on detection of hardware failure to guide users on a computer maintenance page.<p>Computer enthusiast, which are many amongst gamer, are just very eager of this kind of information, discovering it by a game you like that tells you 'check or do that to have a better gaming experience' must be a wonderful and exciting experience.
The author mentions it in passing, and I do wish Starcraft/Broodwar and Warcraft III were open-sourced. Blizzard has understandably chosen to stop updating both games for newer Mac architectures (there is no build for Intel Macs for either, and thus no support for OSX 10.7+). The community would be happy to port the games to new platforms, increasing the popularity of the lucrative franchises.
See also: "select" isn't broken:<p><a href="http://pragmatictips.com/26" rel="nofollow">http://pragmatictips.com/26</a><p><a href="http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html" rel="nofollow">http://www.codinghorror.com/blog/2008/03/the-first-rule-of-p...</a><p>There's nothing wrong with re-discovering things that other people had written about decades before. But discovering the wisdom of the ancients is also helpful.
I think not having the build system match developer systems is a not uncommon source of production issues. It always starts out matching but no one ever updates the build machine (mostly out of fear of breaking something I think).<p>A good strategy I have used is that the first job of a new hire is to "make a build machine" on his or her own machine. Just having new eyes go through the steps on a semi-regular basis catches alot of stuff.
My stackoverflow profile is a sad list of questions like "what's wrong with this library?" which have an answer 2 days later, often by me, saying "it was in <i>this</i> bit of the code."<p>On several occasions I've actually left the bugged lines out of my initial submission, because I thought they weren't important...
This is such an awesome post. When I think about the history of bug fixing it seems like we haven't gone very far in the last couple of years. Measuring how long a bug takes to fix is still voodoo.
99 times out of 100, the bug is yours. Sometimes you really do run into oddball stuff though. The most memorable for me was a bug that only surfaced after you printed something - the printer driver modified the floating point rounding mode and didn't restore it, resulting in some subtle failures of floating point calculations that followed.
I just <i>love</i> his articles: reminds me of the good old days playing these great games.<p>Just a note, he writes:<p><pre><code> "Overheating: Computers don’t much like to be hot and malfunction more frequently in those conditions..."
</code></pre>
One of the reason there are way less spurious crashes of desktop / game apps than back in these days is that now most CPUs have built-in temp sensor that automatically reduce the speed in the case of any kind of CPU overheating.<p>So the piece of code they wrote performing computation and comparing to know good results that could find as much as 1% of broken systems (!!!) would probably not find anywhere near close that number nowadays: the CPU simply slows down if it overheats.<p>Not sure what happens when GPU overheat and if these too have now built-in protection and not sure if they were trying to detect faulty GPUs too.<p>Another common "symptom" was an aunt, uncle, friend of parents, calling and explaining that : "my computer works fine for a while then it doesn't work anymore"... And you'd go check their system, open it, and find a CPU full of dust (which TFA mentions).<p>Nowadays I don't get these calls anymore from those people : they're still using computers, but once their fans get clogged the system simply works at a slower speed and don't overheat anymore.