My biggest mistake as an F1 engineer • Hacker News Board

Re: My biggest mistake as an F1 engineer

#21

Post by friendzis » Thu, Jun 22, 2017, 12:51 PM UTC

fredley wrote: post #10

I'd be interested if anyone has any anecdotes that compare from software engineering. Sending a car out with suspension thingamies still attached seems like the equivalent of pushing a build to production with `DEBUG = True`, and I'm not sure much useful can be learned by you in that situation.

Particularities elided, I was working on a POC of pretty critical (possible damage) closed loop (tightly controlled by operator at the time) system - basically read inputs, react according to algorithm, rinse and repeat. Inputs, however, came from multiple unsynchronised sources and we could arrive at situations where output depended on multiple inputs. I guess we took pretty natural decision to use latest available value of inputs when needed.

During one test run, one input did not update, we were happily feeding stale input to algorithm, which in turn took control paths that could have caused severe damages in unsupervised environment. Lessons learned: if you rely on invariants about inputs in code (update interval in this case), guard against violations of those invariants. This helped me many times later.

Re: My biggest mistake as an F1 engineer

#22

Post by zwieback » Thu, Jun 22, 2017, 1:10 PM UTC

Over the years I've done R&D as well as manufacturing engineering. The closer you are to the manufacturing end the tighter the processes are nailed down, you should still learn for your mistakes but at all times have a controlled default. I'd say the F1 race is like that as well, if the low fuel case was not tried before, which surprises me, it should be a wake up call for the upstream R&D guys to better cover their process space. For the guys on race day it's a sign that process monitoring needs to be improved. Anyway, everyone should benefit in the end and most places I've been have had this attitude. When it comes to learning from your mistakes individuals have a wide set of reactions, though, and it's sometimes tough to swallow your pride and debug the problem in front of you instead of quickly moving on and trying again.

Re: My biggest mistake as an F1 engineer

#23

Post by oblio » Thu, Jun 22, 2017, 1:17 PM UTC

lathiat wrote: post #19

pjc50 wrote: post #13

Earlier quoted context omitted.

If you don't learn something from pushing a debug build to production, your debug build isn't instrumented enough. Maybe all you learn is what the effect of building with/without optimisation is on the real workload. There's practically an entire genre of "here's what I learned from my expensive mistake" stories. Usually they teach humility and caution. This one is interesting because it's a variant of YAGNI. Imagine…

I'd also strongly suggest not typing "exit" into kdb, the Solaris debugger when it is in write mode. It sets the global pointer for exit (the libc function) to NULL and the whole system will crash a few seconds to minutes later when the next process exits. (It's not uncommon to use this tool to reconfigure some configuration values at runtime) At least not on Solaris 10 or any of the open source derivatives. Seems it…

Solaris, the system were ease of use is an enemy.

Re: My biggest mistake as an F1 engineer

#24

Post by pmontra » Thu, Jun 22, 2017, 1:21 PM UTC

> before the race weekend, all our simulations, which had been firmly plotted around a more conventional qualifying strategy, had told us we were likely to finish third.

That was 2006. Do anybody have information about to the software racing teams use to simulate race strategies and how many GPs they test? Thanks.

Re: My biggest mistake as an F1 engineer

#25

Post by djaychela » Thu, Jun 22, 2017, 1:24 PM UTC

I was expecting an error considerably larger than a fuel calculation which ended up giving a better race strategy in terms of surviving the first corner, and netted the same position overall as predicted! I used to prepare my own rally car (up to WRC level), and made many mistakes much bigger than that, but I guess that explains why he works for an F1 team and I'm currently looking for job!

Re: My biggest mistake as an F1 engineer

#26

Post by rconti » Thu, Jun 22, 2017, 1:36 PM UTC

fredley wrote: post #10

I'd be interested if anyone has any anecdotes that compare from software engineering. Sending a car out with suspension thingamies still attached seems like the equivalent of pushing a build to production with `DEBUG = True`, and I'm not sure much useful can be learned by you in that situation.

Google "VW shipping puck" and you'll see this actually happens in the real world all the time, too!

Re: My biggest mistake as an F1 engineer

#27

Post by mooreds » Thu, Jun 22, 2017, 1:37 PM UTC

friendzis wrote: post #21

fredley wrote: post #10

I'd be interested if anyone has any anecdotes that compare from software engineering. Sending a car out with suspension thingamies still attached seems like the equivalent of pushing a build to production with `DEBUG = True`, and I'm not sure much useful can be learned by you in that situation.

Particularities elided, I was working on a POC of pretty critical (possible damage) closed loop (tightly controlled by operator at the time) system - basically read inputs, react according to algorithm, rinse and repeat. Inputs, however, came from multiple unsynchronised sources and we could arrive at situations where output depended on multiple inputs. I guess we took pretty natural decision to use latest available…

So basically treat even invariants as possibly varying.

Re: My biggest mistake as an F1 engineer

#28

Post by chesterc » Thu, Jun 22, 2017, 1:38 PM UTC

haydenlee wrote: post #7

Oh F1 as in cars. I clicked thinking F1 Student Visa.

How can a visa become an engineer, make mistakes and write about them?

Re: My biggest mistake as an F1 engineer

#29

Post by rconti » Thu, Jun 22, 2017, 1:39 PM UTC

Mithaldu wrote: post #9

Short version: He didn't fuel Raikkonen's car up enough which forced an early pit stop in the second-to-last lap of the race. However at the end of the race they placed the same as they had planned, and they had for the laps before the pit stop the advantage of having a stress-free race due to being in pole position. And the lesson he learned from that: Don't stick to the rules too closely, but also try to see if bre…

It was overall a pretty terrible read. Likely because he's not allowed to share full details of what exactly happened.

Running a light fuel load in quali was a well-known strategy, and it's one they would have modeled in simulations. Likewise, avoiding first-lap (and particularly first-corner) collisions by qualifying as high up as possible is similarly a well-known strategy. Finally, they obviously know the money they get from being on pole.

The article doesn't bother explaining why the real-world outcome was different from what was modeled, so it's hard to gain any insight from it.

Re: My biggest mistake as an F1 engineer

#30

Post by koomi » Thu, Jun 22, 2017, 1:47 PM UTC

mickronome wrote: post #16

There is quite a bit of research that implies that the most influential action you can take to make a software team more productive in terms of both quality and quantity is to build a culture that is a close sibling to what he describes. Add in a little more of a socially supportive environment into the professional mindset depicted in the article to adapt it to software develop ent. Psychosocial well-being is essent…

> There is quite a bit of research that implies that the most influential action you can take to make a software team more productive in terms of both quality and quantity is to build a culture that is a close sibling to what he describes.

Can you give us some pointers to said research? I'd love to see the details.