- 0 Posts
- 43 Comments
I learned it while at the same time learning (or really enhancing my previous knowledge of) javascript, thanks to an insane mostly-Finnish app development platform known as Qt Creator, which for no rational reason uses C++ for the under-hood-stuff and javascript for the UI front end. Just an absolutely horrible mismatch of mental states. For bonus points, the company that I worked for that used this monstrosity for its suite of apps got purchased by a huge west coast company and the apps were shut down and everybody was fired, after two years of my working on this shit.
Years ago I got a copy of MSDN which had apparently been put together by developers who all had giant monitors. On a normal laptop screen none of the text wrapped properly so every article had a horizontal scrollbar which you had to work left and right to read every fucking line. I eventually had to start copying the contents into a Notepad instance just to be able to read the damn things normally.
This is why I think developers should always have to work on 10-year-old laptops with 800x600 screens.
It happened because the programmer changed the API from a call that accepted integer values between 0 and 32767 (minimum and maximum wheel speeds) to one that accepted float values between 0.0 and 1.0. A very reasonable change to make, but he quick-fixed all the compiler errors that this produced by casting the passed integer parameters all through his code to float and then clamping the values between 0.0 and 1.0. The result was that formerly low-speed parameters (like 5000 and 6000, for example, which should have produced something like a 20 mph ball with topspin) were instead cast and clamped to 1.0 - maximum speed on both throwing wheels and the aforesaid 125 mph knuckleball. He rewrote his tests to check that passed params were indeed between 0.0 and 1.0, which was pointless since all input was clamped to that range anyway. And there was no way to really test for a “dangerous” throw anyway since the machine was required to be capable of this sort of thing if that’s what the coach using it wanted.
The only projects I’ve ever found interesting in my career was the stuff where nobody had any idea yet how the problem was going to be handled, and you’re right that starting with tests is not even possible in this scenario (prototyping is what’s really important). Whenever I’ve written yet another text/email/calling/video Skype clone for yet another cable company, it’s possible to start with tests because you already know everything that’s going into it.
the code they’re testing has painful hardwired dependencies on expensive external resources
I’ve told this story elsewhere, but I had a coworker who wrote an app to remote-control a baseball-throwing machine from a PDA (running WinCE). These machines cost upwards of $50K so he only very rarely had physical access to one. He loved to write tests, which did him no good when his code fired a 125 mph knuckleball a foot over a 10-year-old kid’s head. This resulted in the only occasion in my career when I had to physically restrain a client from punching a colleague.
The code was to remotely control (from a PDA) a baseball-throwing machine that had a top speed of 125 mph. This dude fucked everything up for more than a year but somehow was kept on the project. They then had him write a version of the software to be used for Little Leaguers. He decided to test out this version for the first time on a field with actual Little Leaguers - the first ball from the machine was supposed to be a slow grounder to the shortstop, but was instead a 125 mph knuckleball a foot over the kid’s head.
If you don’t know baseball, a knuckleball is a ball with no spin so its movement is incredibly random.
Edit: incidentally, the reason this happened is that the guy’s code originally specified the speeds of the two wheels (a baseball-throwing machine uses two wheels with tires spinning at high speed and a baseball is inserted between them and shot out thereby) using Ints with positive values between 0 and 32767. At some point he decided this was clunky (true) and changed the API to accept Float values between 0.0 and 1.0. All well and good, but this produced a big mess of compile errors in his code which he “fixed” by wrapping every call to the speeds method with Clamp ( CFloat ( iSpeedParam, 0.0, 1.0 ) ). His Little League code passed formerly reasonable integer speed values of, say, 5000 and 6000 (which should have produced something like a 20 mph ball with a bit of topspin) which were then cast and clamped to 1.0 and 1.0, meaning both wheels spun at maximum speed, ejecting a ball at 125 mph with no spin.
It was released in 2004. I had a co-worker who was hugely into it in 2005. Entirely coincidentally, he was also into absurdly overcomplicated code and clusterfuck projects that failed after years and millions of dollars.
He was also the only programmer I’ve ever known whose code literally nearly killed a child.
I used to sell windows shareware, a series of apps that composed music and loops etc. I got really sick of finding cracked versions of my apps online, usually a day or two after I’d released something. So I wrote and released an app called “Magic Text Box” which consisted of just a single form with one text box on it. Less than a day later, a cracked version of it showed up.
oftn th lang ony allwd shrt var nms
I started coding with TurboBasic which allowed variable names of any length but the compiler only looked at the first two letters (and case-insensitive at that), so DOUGHNUT_COUNT and DoobieCounter were actually the same variable. Good times debugging that kind of shit.
I don’t know exactly. There’s some process you go through with the IRS to find out what you were paid and how much was withheld in situations like this where the company just goes out of existence suddenly. The IRS has all that info anyway because companies withhold and submit the taxes (at least while they still exist).
A former coworker of mine once learned that his company was shutting down because the office was raided by FBI agents who seized all the computers, servers and company documents. Everybody sat around in the empty office for a little while and then went home, and nobody ever got paid or heard from the company ever again. Even the tax documents at the end of the year didn’t get sent out.
This is my favorite Notepad memory: in the late '90s I went through a six-month stretch where Internet Explorer’s “View Source” command just totally stopped working. It would normally open up the HTML source of a page in Notepad and suddenly not having this made debugging … challenging to say the least. Nobody else that I worked with had this problem and nobody could figure out what had happened to me.
The culprit turned out to be an inexplicable IE bug where View Source wouldn’t work if you had a shortcut named “Notepad” on your desktop. It didn’t even have to be a shortcut to Notepad, it just had to be named that. The fix was to just rename the shortcut “NotepadX” and then View Source worked again.
People always cite this as a reason comments are bad. In 30+ years as a developer I have seen (and participated in) a lot of failed software projects, but not once has a mismatch between comments and code been the actual cause of the failure. Moreover, the same logic could be applied to the names of methods and variables (“if the code changes and the method and variable names aren’t updated accordingly, it can be ambiguous”) but nobody ever suggests getting rid of that. At the end of the day, comments are useful for imparting information about the code to future developers (or yourself) that is too complicated to be adequately communicated by a method name.