3 ms·

Years ago I had one glorious debugging "session" that consumed no less than six months of 12 hour days. I was going absolutely insane. Nobody could figure out

Years ago I had one glorious debugging "session" that consumed no less than six months of 12 hour days. I was going absolutely insane. Nobody could figure out what was going on. This project involved a large FPGA driven by an embedded processor talking to UI code running on a PC. Without getting into technical details I can't cover, things were not working correctly in one particular set of states. I and others went through the relevant code with a microscope, even rewriting some of it out of paranoia. For months we could not figure out what was going on. One glorious Sunday at 2 AM I found the problem. It was an error in calculating the coefficients for a poly-phase finite impulse response filter in the FPGA. The code was calculated in a monster Excel spreadsheet. The coefficients were copy-pasted into the embedded code. The embedded processor loaded them into the FPGA during operation. The thing didn't work. The Excel calculation used the ROUND() function when it should have used ROUNDUP() in the math. An innocent mistake, likely the result of haste. It cost us SIX MONTHS. This incident, perhaps more than anything else, made me recoil at the idea that code entry speed is in any way relevant to the delivery of working bug-free product. It truly isn't. In fact, going fast can cost you dearly.

catdog 7y ago
https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug comes to mind
- robomartin 7y ago
  Yeah, that was a good one. Engineering of good reliable products, whether software-only or multidisciplinary has nothing whatsoever to do with the ability to enter or edit text quickly or efficiently. I am not sure they care --given what they wrote I don't think they do-- but it is very wrong for a respected entity like MIT to spread false information, as is the case with the nonsense they wrote in this CS course regarding vi/m. At the very least it betrays an utter lack of knowledge of history and, even worse, a fabrication of a preferred narrative and reality. These editors did not come to exist for any reason other than we had crappy character-only screens, crappy keyboards, no GUI's and terminals that communicated with computers at 1200 BAUD. Package all of that together and the only thing that makes sense is something like vi. In that context vi made sense. In fact, it was necessary. Evolve all of that to modern hardware, UI's and performance and one would never author such a tool, not even close, in fact, one would be laughed out of the room --and rightly so.

catdog 7y ago

https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug comes to mind

robomartin 7y ago
Yeah, that was a good one. Engineering of good reliable products, whether software-only or multidisciplinary has nothing whatsoever to do with the ability to enter or edit text quickly or efficiently. I am not sure they care --given what they wrote I don't think they do-- but it is very wrong for a respected entity like MIT to spread false information, as is the case with the nonsense they wrote in this CS course regarding vi/m. At the very least it betrays an utter lack of knowledge of history and, even worse, a fabrication of a preferred narrative and reality. These editors did not come to exist for any reason other than we had crappy character-only screens, crappy keyboards, no GUI's and terminals that communicated with computers at 1200 BAUD. Package all of that together and the only thing that makes sense is something like vi. In that context vi made sense. In fact, it was necessary. Evolve all of that to modern hardware, UI's and performance and one would never author such a tool, not even close, in fact, one would be laughed out of the room --and rightly so.