What’s keeping me from going as fast as I can as a software developer? Reading your blog entries; they’re too good!
Give a developer a slow machine, and save hundreds/thousands of users hours of waiting apiece.
Just a couple days ago, after getting a new PC, I encountered a bug in a game from 2001, the speed estimating function ran too fast and returned zero while its caller never expected that. Result - unhandled divide by zero exception.
I remember the same type of crash happening when certain DOS Pascal programs ran on the first 32 bit chips… something to be said about learning from history.
(The game is CC Yuri’s Revenge, btw, and luckily I’m versed enough in assembly to fix that bug /and a lot more bugs in the CC series/ myself.)
My computer has two buttons: Turbo and Ultra-Turbo! (That makes it go to 11.)
From the codist:
I could write code, compile it and run it at the same time.
I could write, compile and debug applications virtually instantly
Surely he is some kind of god! We worship you, O Codist! Lo, let not your wrath fall upon our heads, for we are weak and mortal and sometimes it takes finite amounts of time for us to write even a ‘Hello World’ program!
Games for the most part don’t use speed detection algorithms to slow the games down intentionally… they use better techniques to manage what’s going on over the course of a time line, animations for example simply transition over time mathematically.
Didn’t you post an argument against optimising code just a few days ago? Just to throw more money at it, I think was your point.
Personally, I’d like to see hardware speeds hit a ceiling for 5-10 years before they pick up again.
What really irks me, performance wise, is every application’s need (often due to their dependant libraries) to thrash the hard drive. Why is it that Firefox is an 8.5 meg download, yet the hard drive activity when launching it is roughly on par with copying a 100 Mb file? (Even with no cache or personal data.)
I’d LOVE to have five years of fixed-speed hardware, so that software learns how to be fast again.
Things should definitely happen instantaneously on computers, if it takes more than 3ms to open the start menu in Xp, its time to reinstall.
I used the turbo button when I wanted to see what was happening while booting. If I had some kind of hardware crash I could see what things were loading and what was messed up. I think I was only 10years old at the time so I didn’t really understand what I was doing and I’m not sure if it actually solved any problems but I remember it all non the less 
MARTIN YOU SUCK.THE 1 GB FRAMEWORK DOES MAKE PROGRAMMING EASY NOT THE NOTEPAD!
I recall that Linus T. wrote ‘git’ so that code ‘merges’ ocurred near instantly…
would performance like he describes (merge rapidly and often) be enough to convince you to change your software version management software?
I read this blog while waiting for: VS to compile, TFS to get latest, tests to run. I would get 40% more done in a day if everything was instant. The 2 minutes I have to wait kills my productivity, my mind wanders and I get side tracked (like right now).
And its not like my machine is slow: quad core 3GHz, 8GB RAM, RAID-0. Most of my coworkers think I’m crazy when I complain about waiting 2 minutes for a compile. Anything longer than a few seconds is too long!
I had a 386/33MHz which could be overclocked to 40MHz by connecting 2 motherboard pins with a jumper. I connected these pins to the case’s turbo button, an voila - a real Turbo button! I even hacked the 7-segment MHz display to show correct numbers.
I remember the game Test Drive running on our 8088. The car was simply not drivable without the Turbo OFF. It was too fast. Some games were CPU clock independent, and some others were CPU clock dependent.
Obviously, game programmers at Accolade got it wrong for Test Drive.
I don’t think your snippet from Fred brooks has anything to do with what you are talking about. It seems to be taken out of context and fit in your article to give you more credibility. In fact, I would suggest that sometimes such immediacy is sometimes detrimental to comprehending problems and understanding systems. Too often I see people just use a compiler and linker combined with trial and error to get things working. Sometimes it has desired effects, but many times it allows weak minds and weak developers to compile and check in bad code without understanding anything they were doing. I don’t yearn for the olden days of slow responses, but I think we have gotten to the point where many developers don’t even think about what they are doing before writing code. The instant feedback exacerbates that.
@Mick: That is true for the compiler itself. But the debugger takes ages to start up (rearranging all those windows).
Plus performance is not everything: The compiler is so full of bugs, I decided to stop using Delphi 2009 until (at least) SP3 (too bad I already purchased it.
My ‘turbo button’ is almost always non-responsive customers. Wait a day to get back to me on an issue, don’t look at the sample screenshots I sent you, or keep forgetting to have IT set up that user account, and my interest in your project slows to 16Mhz.
Oh and there is a nice counter example: The fastest N64 emulator (Corn) was created by a Russian genius who (as far as I know) simply could not afford a faster machine. It ran flawlessly on a 200-300 mhz machine (which is awesome, considering the N64 was a MIPS running at 93 Mhz plus a coprocessor running at 66 Mhz (if I recall correctly)).
Maybe the rule should be: Developers should have fast machines to be productive but should test their software on damn slow hardware.
P.S.: UltraHLE was also damn fast but due to slowdown routines that could not be disabled it is very difficult to compare those two emulators.
In addition to Peter Turner’s comment about Space Quest 1,
our little turbo button was also helpful while trying to hit the spider which came from an outer space.
The problem wasn’t that programs weren’t written to run on different clockspeeds, which there were even then a multitude of by the early nineties. The problem was a lot of those program’s calibration loops didn’t do enough iterations and so on a 486 a loop that went around 100 times to estimate a slowdown-number to pauze between frames completed in 0.0 seconds and so the game crashed with a divide by zero error.