Ramsay's kitchen nightmares, but for software development
-
Please elaborate on this knuckle ball story. I am confusion.
wrote on last edited by [email protected]We got hired by a company that was developing a remote-controlled baseball launching machine. The machine itself was just the standard two spinning wheels (although the max rotational speed of 125 mph was a lot for this sort of thing), but it could also pivot 360 degrees and also angle itself between straight up and 45 degrees down towards the ground, so it was capable of simulating any hit ball in baseball. The idea was that you would put this machine at home plate and then the coach could walk out among the players and use the remote (which was a Windows Mobile PDA) to generate any kind of hit, like a grounder to short or a pop fly to right field etc. Because the wheels could be independently controlled, you could put any kind of spin you wanted on a ball by having one wheel spinning faster than the other.
Really a cool device and a cool project, but my coworker who got the gig was a remarkably terrible programmer who spent more than a year fucking things up in various ways. At one point, for example, he spent three months trying to develop a Physics engine to control where the ball went, despite the fact that a) he knew nothing about Physics, and b) the Physics of a spinning baseball is actually incredibly complicated and well beyond the processing power of a PDA circa 2005. Not to mention that the balls used varied tremendously in how old and scuffed up they were, which would have defeated any attempt to calculate where they were going with any kind of real precision.
Despite being well over budget and past the original schedule, he had things sort of working (sometimes) and the client asked him to produce a variant of the software that would let the machine be used by Little League coaches. My coworker in addition to writing the version to scale back the speeds appropriately, also decided to completely change the API that was used to communicate with the machine. Previously, the speeds had been specified by short integer values between 0 and 32768, but he decided it would be better to use floating-point values between 0 and 1. All well and good, except his way of dealing with the huge amount of compiler errors this generated was to cast all the hard-coded short int values as floats and clamp the result between 0.0 and 1.0.
As bad as this was, he also decided to test this version - for the first time - on a field with actual Little Leaguers (in his defense - but only slightly - we rarely had access to the actual machine itself, so proper testing was always difficult). The coach sent the command for a slow grounder to the shortstop. This should have produced a horizontal ball with about a 30 mph speed on the bottom wheel and 35 mph on the top wheel to give it some topspin. Instead, his hard-code int values were about 10000 and 12000, which got cast and clamped to 1.0 by the API call - in other words, maximum speed (125 mph) on both wheels. This ejected a ball with no spin going 125 mph, the most deadly knuckleball in human history (human pitchers throw knucklers at maybe 50 mph and they're nearly impossible to hit or even catch). At least he had the angle and azimuth "right" so this was fired straight at the shortstop! Had it hit him, the kid for sure would have badly concussed and very possibly killed, but fortunately it sailed just over his head.
-
We got hired by a company that was developing a remote-controlled baseball launching machine. The machine itself was just the standard two spinning wheels (although the max rotational speed of 125 mph was a lot for this sort of thing), but it could also pivot 360 degrees and also angle itself between straight up and 45 degrees down towards the ground, so it was capable of simulating any hit ball in baseball. The idea was that you would put this machine at home plate and then the coach could walk out among the players and use the remote (which was a Windows Mobile PDA) to generate any kind of hit, like a grounder to short or a pop fly to right field etc. Because the wheels could be independently controlled, you could put any kind of spin you wanted on a ball by having one wheel spinning faster than the other.
Really a cool device and a cool project, but my coworker who got the gig was a remarkably terrible programmer who spent more than a year fucking things up in various ways. At one point, for example, he spent three months trying to develop a Physics engine to control where the ball went, despite the fact that a) he knew nothing about Physics, and b) the Physics of a spinning baseball is actually incredibly complicated and well beyond the processing power of a PDA circa 2005. Not to mention that the balls used varied tremendously in how old and scuffed up they were, which would have defeated any attempt to calculate where they were going with any kind of real precision.
Despite being well over budget and past the original schedule, he had things sort of working (sometimes) and the client asked him to produce a variant of the software that would let the machine be used by Little League coaches. My coworker in addition to writing the version to scale back the speeds appropriately, also decided to completely change the API that was used to communicate with the machine. Previously, the speeds had been specified by short integer values between 0 and 32768, but he decided it would be better to use floating-point values between 0 and 1. All well and good, except his way of dealing with the huge amount of compiler errors this generated was to cast all the hard-coded short int values as floats and clamp the result between 0.0 and 1.0.
As bad as this was, he also decided to test this version - for the first time - on a field with actual Little Leaguers (in his defense - but only slightly - we rarely had access to the actual machine itself, so proper testing was always difficult). The coach sent the command for a slow grounder to the shortstop. This should have produced a horizontal ball with about a 30 mph speed on the bottom wheel and 35 mph on the top wheel to give it some topspin. Instead, his hard-code int values were about 10000 and 12000, which got cast and clamped to 1.0 by the API call - in other words, maximum speed (125 mph) on both wheels. This ejected a ball with no spin going 125 mph, the most deadly knuckleball in human history (human pitchers throw knucklers at maybe 50 mph and they're nearly impossible to hit or even catch). At least he had the angle and azimuth "right" so this was fired straight at the shortstop! Had it hit him, the kid for sure would have badly concussed and very possibly killed, but fortunately it sailed just over his head.
The fuck??? That's a horrible co-worker…
-
We got hired by a company that was developing a remote-controlled baseball launching machine. The machine itself was just the standard two spinning wheels (although the max rotational speed of 125 mph was a lot for this sort of thing), but it could also pivot 360 degrees and also angle itself between straight up and 45 degrees down towards the ground, so it was capable of simulating any hit ball in baseball. The idea was that you would put this machine at home plate and then the coach could walk out among the players and use the remote (which was a Windows Mobile PDA) to generate any kind of hit, like a grounder to short or a pop fly to right field etc. Because the wheels could be independently controlled, you could put any kind of spin you wanted on a ball by having one wheel spinning faster than the other.
Really a cool device and a cool project, but my coworker who got the gig was a remarkably terrible programmer who spent more than a year fucking things up in various ways. At one point, for example, he spent three months trying to develop a Physics engine to control where the ball went, despite the fact that a) he knew nothing about Physics, and b) the Physics of a spinning baseball is actually incredibly complicated and well beyond the processing power of a PDA circa 2005. Not to mention that the balls used varied tremendously in how old and scuffed up they were, which would have defeated any attempt to calculate where they were going with any kind of real precision.
Despite being well over budget and past the original schedule, he had things sort of working (sometimes) and the client asked him to produce a variant of the software that would let the machine be used by Little League coaches. My coworker in addition to writing the version to scale back the speeds appropriately, also decided to completely change the API that was used to communicate with the machine. Previously, the speeds had been specified by short integer values between 0 and 32768, but he decided it would be better to use floating-point values between 0 and 1. All well and good, except his way of dealing with the huge amount of compiler errors this generated was to cast all the hard-coded short int values as floats and clamp the result between 0.0 and 1.0.
As bad as this was, he also decided to test this version - for the first time - on a field with actual Little Leaguers (in his defense - but only slightly - we rarely had access to the actual machine itself, so proper testing was always difficult). The coach sent the command for a slow grounder to the shortstop. This should have produced a horizontal ball with about a 30 mph speed on the bottom wheel and 35 mph on the top wheel to give it some topspin. Instead, his hard-code int values were about 10000 and 12000, which got cast and clamped to 1.0 by the API call - in other words, maximum speed (125 mph) on both wheels. This ejected a ball with no spin going 125 mph, the most deadly knuckleball in human history (human pitchers throw knucklers at maybe 50 mph and they're nearly impossible to hit or even catch). At least he had the angle and azimuth "right" so this was fired straight at the shortstop! Had it hit him, the kid for sure would have badly concussed and very possibly killed, but fortunately it sailed just over his head.
Wow thank you for sharing. Very interesting story.
-
The fuck??? That's a horrible co-worker…
And this wasn't even his biggest disaster as long as you don't count the potential for death. The baseball-throwing gig was just him and his manager; for his next project he led a team of five developers that turned three months into three years and never produced working software. The only revenue it ever produced was an initial $50K from the client that was later refunded to preempt a lawsuit. For the project he chose Ruby-on-Rails despite the fact that neither he nor anybody else on the team - nor anybody else in the entire state for that matter - had any experience with RoR. I have to give him credit, though: he was a true Renaissance Man in the sense that he could fuck up a project in any language or platform.
-
And this wasn't even his biggest disaster as long as you don't count the potential for death. The baseball-throwing gig was just him and his manager; for his next project he led a team of five developers that turned three months into three years and never produced working software. The only revenue it ever produced was an initial $50K from the client that was later refunded to preempt a lawsuit. For the project he chose Ruby-on-Rails despite the fact that neither he nor anybody else on the team - nor anybody else in the entire state for that matter - had any experience with RoR. I have to give him credit, though: he was a true Renaissance Man in the sense that he could fuck up a project in any language or platform.
Now, I don't have to be embarrased at the hobby project forks I make. Thanks!
-
This post did not contain any content.
You fucking Donkey!
-
Yes, but consider that the abbreviations alone would make the show unwatchable. "Hold on, babe, what's a SaaS?"
Could use subtitle style helpful info like in Alone
-
You joke, but I've actually been responsible for a coder getting shown the door for running a coin miner on his work laptop.
In his defense, cyber security at that company was crap for a long time. After a ransomware outbreak, they started paying attention and brought some folks like myself in to start digging out. This guy missed the easy out of, "hey that's not mine!" The logs we had were spotty enough that we would have just nuked the laptop and moved on. But no, he had to fight us and insist that he should be allowed to run a coin miner on his work laptop. Management was not amused.
Am I just stupid or does that seem like an extreme reaction?
Apart from the ~0% profitability these days, what's the issue with running a coin miner? -
This post did not contain any content.
Cute silly furry
-
Still have a copy of Ubu 8.04 on CD somewhere.
Not sure if it still works though.Good times.
I wonder if there is a forgotten torrent of the ISO somewhere floating around with users still seeding it
-
This post did not contain any content.
Someone would have to look at and understand the existing code and infrastructure rather than just throwing it all away and writing a data migration. In other words, it would never happen.
-
It surprises me that there aren't more shows like that, just some random dude bursting through your job calling you all twats and pointing out where you failed, then helping you fix it.
I want carwash nightmares or retail nightmares shows.
Startup nightmares would either be cathartic or give me ptsd flashbacks.
-
Am I just stupid or does that seem like an extreme reaction?
Apart from the ~0% profitability these days, what's the issue with running a coin miner?Analogous to someone using the company car to make some extra money as a uber/lift driver. Do you still not see the problem?
-
This week I heard from a network group lead of a university hospital, that they have a similar issue. Some medical devices that come with control computers can't be upgraded, because they were only certified for medical use with the specific software they came with.
They just isolate those devices as much as possible on the network, not much else to do, when there is no official support and recertification for upgrading. And of course nobody wants to spend half a million on a new imaging device when the old one is still fine except for the OS of the control computer.
Sounds like a shitty place to be, I pity those guys.
That said, if you were talking about normal client computers then it's inexcusable.
It baffles me that medical device manufacturers use windows for fucking anything. You'd think just the licensing cost would push them away, but it being hot garbage for embedded software should have been enough. It's amazing any medical device certification process would allow them to use it at all, with the notorious unreliability and not giving a shit what you think about updates. People could die because of a fucking windows update at the wrong time.
-
This post did not contain any content.
Silicon Valley
-
This post did not contain any content.
Me and friends borked our school network by making it a doge coin miner in high school, the IT guy was not pleased.
-
This post did not contain any content.
It's called incident response
-
Am I just stupid or does that seem like an extreme reaction?
Apart from the ~0% profitability these days, what's the issue with running a coin miner?Besides the general security risk of they run trojaned clients, if they run it in the office they're spending the company's electricity
-
This post did not contain any content.
I would watch this. Maybe something like "SRE Squad" with like a fire department type aesthetic and eagles and flags and butt rock theme song.
-
Analogous to someone using the company car to make some extra money as a uber/lift driver. Do you still not see the problem?
Kinda, but not as a firable offense.
Using the company car for uber would raise the odometer, wear the tyres, use fuel, risk crashing, etc..As long as things are within thermal limits, it won't risk damaging the device.
I guess it could make the battery degrade quicker, but it seems so insignificant in comparison.
