@@ContinuousDelivery Reality just waiting to catch up. The internet is full of beginner-level information. What we need is more from Master Craftsmen & women like yourself
I also use SpaceX as an example to explain DevOps. It's just a perfect metaphor. Especially the fundamental ideology in SpaceX to make EVERYTHING testable (meaning that they don't even use explosive bolts because they are not testable).
I am a software engineer too and have become enthralled with Tesla. Totally agree with your thinking that Tesla brought CI / CD to the auto industry and learned how to fail fast and cheap. Truly amazing. You would enjoy youtubers, Dave Lee on investing, and Steven Mark Ryan Solving the Money Problem. I will forwards these videos on to them. Having a video talking them would be very worthwhile. I believe you mentioned Sandy Munro. You may find Tony Seba on auto / energy / transportation disruption quite fascinating too.
Applied to growing a RUclips channel: Keep using buzzwords that the algorithm likes :) Your Cyberpunk video allowed me to find your channel. It‘s great source of information and inspiration. Keep it up!
Yes, my strategy is to do what I can to get my stuff in front of people, but not to compromise the content. I am not chasing rankings for the sake of it, or I'd be doing videos about dancing cats 🤣 my ambition is to be able to help people with what I think is useful and interesting ideas. So we will continue to pick titles that hopefully bring people in, and content, that people find helpful and interesting.
This channel is so addicting. You describe everything so methodically, it's hard to find weak points in any arguments or analogies you make... quite a good indicator!
One thing Elon Musk also said that do apply to programming as well is this: "The best part is no part. The best process is no process. It weighs nothing. Costs nothing. Can’t go wrong".
Contrary to popular opinion, the "guesses" of the pubic are NOT the same as those of engineers and scientists. I don't think most of us really understand how little we actually know, and underestimate and undervalue the knowledge of those that have spent their whole lives learning a domain. I used to get mad when my boss told me a product design was "simple" and that "anybody could do it". Its not hard to make something complicated. Hard to make something simple. I'm also happy that my own natural (coding) workflow is that of Continuous Delivery. Every time I DON'T screw something up in code, I commit it as my "latest good" code, then go to the next small iteration. It is hard to stay focused though, as everything I encounter on debugging makes my want to go fix other stuff too lol.
So helpful. I occasionally consult with aerospace firms on development processes that have to comply with DAL A, DO178 and Milspec. I always run into barriers for efficiency because of old school practices for software assurance that work but are slow. I didn’t know space x was so open on their processes. Will use this as a great example of process and you can do it too evidence.
I have not done much work with orgs doing military software, but have done a lot in other regulated industries. There is a move to apply these techniques in those, and in the military, because they work better! There is some interesting stuff published by a variety of US military sources, here are a couple of interesting links: software.af.mil/wp-content/uploads/2019/12/DoD-Enterprise-DevSecOps-Initiative-Keynote-v1.7.pdf dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf
Amazing content! While most software engineering channels focus on superfical things like framework x or algorithm y, one can see a deep understand of fundamental concepts and a scientific approach to the way you are explaining things. Kudos!
I think you might like to read the story behind the gossamer condor, the first human powered aircraft. Precisely by iterating it succeeded where competitors failed.
The SpaceX software team has now had two AMA's on Reddit as far as I know. I thought you would speak to what they said about software development directly, as well. Could you?
In terms of software development my honest answer is that I don't know. I would be quite surprised if they are not though, they are moving very fast and with good quality, but beyond that Tesla are significant implementers of Continuous Delivery for all the software in their cars, and, of course Tesla and SpaceX are both Elon Musk companies. I do plan to do a video in future on the Tesla approach to CD, because they have published a fair bit on it and there is some interesting stuff there.
Just some thoughts/concerns regarding pure Agile in Embedded: I don't know if continuous delivery, in this case, adds any value because you have to test the software, and I don't think they have recordings from older projects, and these recordings can be adapt for testing this specific product! They will probably test in a 100% synthetic environment, which is not the reality! So maybe it will be a better approach to follow (focus) a "rigid" plan in the early stages of the project (which probably is very complex for certain ECU's) than weekly deliver aspects/features of the software that can not be 100% testable. Agile makes customers happier, we all know that, but it doesn't mean the code's quality will be better in all instances. Embedded has a different/specific need than PC SW, so at least for some projects (you mention Tesla - especially ADAS projects), a combination between Waterfall and Agile is more suitable than pure Agile/Waterfall! For embedded, in some specific domains, a pure Agile approach can represent a greater risk, for example: In an ADAS project where you have 20-30000 CUSTOMER requirements (broad req not refined req), you need VERY knowledgeable feature teams (understanding the whole picture) to prioritize features and consider all the standards/legislation/etc. related to this req when they implement and test the code. Just do not forget! ECU's purpose in this kind of project is to interact with the environment like a human been, prevent accidents, and save lives.
@@devianceRo Actually the data, for Continuous Delivery at least, says that the quality is significantly higher (see "state of DevOps reports"). Teams often/usually see orders of magnitude reductions in defect counts for example. I do quite a lot of work with teams that have embedded systems as part of their portfolio. I think that the shift is to stop thinking of testing as a "once you are finished with dev" kind of activity and rather an inherent, guiding principle for development. That way we design for testability, which has the knock-on effect of also improving the quality of our designs. This is what I really mean when I speak about "engineering" in the SW context.
Hi Dave, long time no speak. Really appreciating the content on the channel. Where do you see other related disciplines fitting into "engineering"? I'm thinking business analysts, UX, the idea of lo-fi prototypes, minimum viable products and the like. Obviously our focus as coders is rightly on the deployment pipeline, but there is usually a whole set of work before new ideas make it to developers. Cheers, Chris (ex Waters)
Chris, how are things? My view is that it is about thinking in terms of experimentation. "What is my theory?", "How could I test that theory", "What do I want to learn", "What info do I need to gather to learn it?", "What variables can I eliminate, so that the answers are clearer". I think that, at this level, practical science (engineering) is pretty generic. UX is a good example, www.fastcompany.com/1403230/googles-marissa-mayer-assaults-designers-data
Very good Channel Dave. As a learner I've realized there was a lack of this information you teach on RUclips which I've come to realize isn't good. Refreshing not to see another "Netflix" or "Twitter" clone app being done!
Just a weird question that popped in my head while watching this, what did they use to test the testing software as they developed it? Great content as always.
I would love to know more about SpaceX's approach to software development. I know that Tesla run a pretty sophisticated Continuous Delivery approach, I plan to do a video on that at some point. I would imagine that SpaceX do something similar.
Hello Dave, can you make/do you already have a video that explains the shape of your pipeline diagram? It does look circular, but its supposed to be linear (coz you know it is a pipe"line"), I full don't get the lines between the stages, sometimes a stage is drawn at the center of the circle. I know there is reasoning behind it, I just don't understand it. Can you help a viewer please?
The circle is just a way to fit a pipeline into a diagram better. Actually the pipeline is named for "Instruction Pipelines" in Intel processors, as it is a kind of "branch prediction optimisation". Here are a couple of videos that go into a bit more detail... Pipeline Webinar: ruclips.net/video/ONnwToAH4bU/видео.html Pipeline Explained: ruclips.net/video/x9l6yw1PFbs/видео.html I also have a very good training course on the subject 😁
Funny, just found your channel - great, thanks :) - and was about to suggest you to do a video on starship as seemingly the first CD pipeline for rocket design.... Dunno if you just skipped it but Musk cited the rate of build and change with steel vs carbon as a key, if not the primary driver of change, along with cost and temp. perf as you noted. Talks about it in September 2019 starship update.
Awesome video once again Dave. Love the real world / company focus to help things from being too theoretical. Great approach, super clear and would love to see more like it. What about another video game company that is developing / engineering with modern CI/CD practices?
EPIC's Fortnight could be a good example to look into. (not a fan of the game myself but their ability to churn out new content and features is second to none)
@@l_combo I am not sure if Fortnite is the best example because as far as I understand they tend to make somewhat extreme changes each season rather than iterative changes so the experiments they run are not well controlled. This is not a very scientific approach. In terms of engineering practices, Nintendo proper is probably one of the best game companies. They experiment heavily rather than rely on common practices and conventions and throw out stuff that doesn't work. And their games are some of the best engineered in the business.
This is an interesting definition of engineering, it sort of sounds like you are redefining engineering as science, rather than just calling software development a science. If engineering is the process of applying the scientific method to solve problems (as apposed to the engineering design process), then what is science?
I would like to get behind the "engineers are optimizing for learning" idea. And with SpaceX you are probably right. But what about engineers that build bridges (or gears, or ..). I would assume, that they simply apply existing knowledge to a problem. How far away are we from the point that a computer could independently generate the plans for a bridge that would work. (Probably 100 Variations of wich the major could than select one that satisfies his ego the best ) My point: The whole learning thing is only true if you do something new. Most SW projects are that way, and SpaceX stuff is, too. But not all of engineering is.
That kind of is my point, that in SW we are always "doing something new" so SpaceX is a good example for us. In SW the "cost of production" is so low that it may as well be free. That means that we'd be dumb to reproduce stuff that we already have, so we are always, within the context of a development, working on something new. That doesn't mean that no one has ever done it before, but it is ALWAYS at least new to the team working on it. I think that bridge-building is, in reality, probably less "cookie-cutter" than we SW devs think, but even if it is, that is about production engineering, not design engineering, we are always - ALWAYS in the design-engineering space. So I do think that SpaceX offers some interesting pointers for us.
Software has been in use to support civil engineers for decades. Designing a bridge, or parts and materials for a jet engine, or any other materials engineering endeavour, is prone to involve computer calculations and many iterative simulations. Engineers consider simulations as irreplaceable. Simply applying rules of thumb is the old way. The very old way.
I thought this was going to be about software engineering at SpaceX, but instead it's using SpaceX's hardware engineering practice as an example of how to do software engineering. The analogy doesn't seem super apt. Does SpaceX actually do its *software* engineering in the way you describe?
Except starship is not production-ready and doesn't pretend to be. So it really argues in favour of Prototyping and against Continuous Delivery if anything. Wouldn't Continuous Delivery advocate iterating on Falcon 9 instead? (which SpaceX has also done)
I see your point, but I see no reason why Starship isn't a CD project too. In fact I can see direct analogies in some of my own work. They built a system, in Falcon 9 (in my case a simple Financial exchange) that worked, but couldn't do all that was needed. Falcon 9s are never going to open up Mars exploration, my exchange wasn't fast enough. So you take your learning from that and start working on somehting that has a better chance of doing what you need. The next question is what does "production-ready" mean? For the StarHopper it needed to fly 150m up and then land. That was it's version of production. For SN15, which has recently landed successfully, then it's version of "prod-ready" meant that it could fly to 12km and land back on the pad. It seems to me that "Design Engineering" is always incremental, experimental, in this way, but just because you are iterating doesn't stop you switching tracks when what you learn says "this route won't get you where you want to be".
What do you mean by "when was the last time you heard software engineers speaking like this?"? Speaking like what? About steel, temperature and basic physics concepts? I'm a game developer in in my day-to-day routine I have to deal with much more abstract problems to think how to accomplish features while optimizing performance. Not steel, aluminum, carbon - that every normal person can understand, but meshes, vertices, pixels, etc or language related like Arrays vs Lists (performance vs ease of use), etc, etc. We software engineers work on a level of abstraction above everyone else.
No matter what layer of abstraction you are working in you still have to explain why a particular decision makes more sense. I choose X data structure over Y data structure because even though its more expensive in memory its faster. Terms that anyone can understand. I'm a programmer by trade but I have a Mechanical Engineering degree. Mechanical Engineering uses the same tools as software developer such as vertices, linear algebra, etc. For example how would you model stresses over complex geometry of a part say a car? Ultimately as a mechanical engineer or a game programmer we still have to explain things to people outside of our trade in terms that make sense. Most often in dollars and time :).
Yes exactly! I think that all too often we miss that important rationale. Quantum physicists don't say "this is really hard, so let's just guess instead", well maybe they do a bit, but the important thing after the guesses is to figure out how to make our decisions more rational.
I was speaking by analogy, when was the last time that you made a decision in software based on measurement rather than guesswork? Do you know the performance characteristics of the data structures and collections that you use? Do you think about the big 'O' number before choosing? I am not suggesting that you need to know the temperature of your software or its tensile strength but what is the equvalent? How many bytes per entry does a hashmap add compared to an array? I can tell you the answer for that in the version of Java that I used when building trading systems, because it matters, it matters in terms of the size of the models that you can hold in memory and, maybe more importantly for trading, and maybe for games, it matters in terms of performance. If your hashmap entries take more space that means a higher cost to move them into the CPU, a higher cost to copy them, a higher cost to garbage collect them too, depending on how that works. These too are only simplistic examples. I think that the important idea is that we should think about what we can, and should, measure and understand in order to work on the basis of knowledge rather than guesses and fashion. That is even more important for software than for rocket engineers, because our stuff is so abstract, maths is pretty abstract too, but that doesn't mean that they give up, we, as an industry, have mostly given up on rational decision-making.
I interpreted this slightly differently to you. Carbon fibre could be the year's fashionable tech that everyone wants on their CV - block chain, rust, kubernetes, event buses, whatever. All good at some things, but often selected because everyone else is doing the same. Steel is good old C++, Java, C#, clean code, etc. No one would get excited about these things, but they get the job done.
Well, I think they did what you'd expect. You start with a guess, "let's use CF cos everyone is raving about the strength to weight ratio", then you start assuming how your guess is probably wrong, and looking at the ways that it may be wrong to see how that starting point plays out. In this case, it was too expensive and not strong enough for its weight at some important operating temperatures. I think that there is a lot to be said for "boring tech" sometimes, lots of people have experience of it, and so we know the wrinkles. the reason that I highlighted it here, is because I think that analogous decision making is so rare in software. Even when we do tech bake-offs, we are often extremely subjective in the criteria that we apply. This is one of the reasons that the Stability & Throughput measures from the "Accelerate" book as so important. They give us a bench-mark that we can use. "If I pick this tech, does it make my quality higher (Stability) or my efficiency better (Throughput)?". If if makes them worse, don't do it, if they are the same, only then decide on subjective qualities.
Have you been following the Video Card price inflation due to crypto miners? Elon Musk should get into that... All he would need to do is figure out a way to get video cards to customers without the dip in supply.
I think he is doing fairly well on his current projects too. 🙂 www.forbes.com/sites/sergeiklebnikov/2021/01/14/elon-musk-is-the-richest-person-in-the-world-again/
I didn’t say a “live stream of SpaceX developing software” I was referring to the live stream of SpaceX doing engineering, developing their rockets, in public, on RUclips.
Such an underrated channel! Your content is great!
Thanks, I am pleased that you are enjoying it.
@@ContinuousDelivery Reality just waiting to catch up. The internet is full of beginner-level information. What we need is more from Master Craftsmen & women like yourself
As a computer application student loved ur content...
This guy is the human embodyment of the word "engineering"
Wow! Thank you 😎.
or did you mean Elon Musk 🤣
I also use SpaceX as an example to explain DevOps. It's just a perfect metaphor. Especially the fundamental ideology in SpaceX to make EVERYTHING testable (meaning that they don't even use explosive bolts because they are not testable).
I didn't know that about the bolts, I will look it up, thanks.
I am a software engineer too and have become enthralled with Tesla. Totally agree with your thinking that Tesla brought CI / CD to the auto industry and learned how to fail fast and cheap. Truly amazing. You would enjoy youtubers, Dave Lee on investing, and Steven Mark Ryan Solving the Money Problem. I will forwards these videos on to them. Having a video talking them would be very worthwhile. I believe you mentioned Sandy Munro. You may find Tony Seba on auto / energy / transportation disruption quite fascinating too.
Applied to growing a RUclips channel: Keep using buzzwords that the algorithm likes :)
Your Cyberpunk video allowed me to find your channel. It‘s great source of information and inspiration. Keep it up!
Yes, my strategy is to do what I can to get my stuff in front of people, but not to compromise the content. I am not chasing rankings for the sake of it, or I'd be doing videos about dancing cats 🤣 my ambition is to be able to help people with what I think is useful and interesting ideas. So we will continue to pick titles that hopefully bring people in, and content, that people find helpful and interesting.
@@ContinuousDelivery Next Video: What can we learn from dancing cats..
Optimize for learning, what a great advice. Not only for engineering, or software developing, but for all fields, for life.
Yes, its a positive approach, widely applicable.
Great videos, last days I often realize I'm trying to find a video on your channel that I haven't watched yet 😀
This channel is so addicting. You describe everything so methodically, it's hard to find weak points in any arguments or analogies you make... quite a good indicator!
Thanks!
One thing Elon Musk also said that do apply to programming as well is this: "The best part is no part. The best process is no process. It weighs nothing. Costs nothing. Can’t go wrong".
Not really the same thing. My bet is that Elon Musk would not throw away science and engineering practice, those are 'process' too.
Contrary to popular opinion, the "guesses" of the pubic are NOT the same as those of engineers and scientists. I don't think most of us really understand how little we actually know, and underestimate and undervalue the knowledge of those that have spent their whole lives learning a domain. I used to get mad when my boss told me a product design was "simple" and that "anybody could do it". Its not hard to make something complicated. Hard to make something simple. I'm also happy that my own natural (coding) workflow is that of Continuous Delivery. Every time I DON'T screw something up in code, I commit it as my "latest good" code, then go to the next small iteration. It is hard to stay focused though, as everything I encounter on debugging makes my want to go fix other stuff too lol.
So helpful. I occasionally consult with aerospace firms on development processes that have to comply with DAL A, DO178 and Milspec. I always run into barriers for efficiency because of old school practices for software assurance that work but are slow. I didn’t know space x was so open on their processes. Will use this as a great example of process and you can do it too evidence.
I have not done much work with orgs doing military software, but have done a lot in other regulated industries.
There is a move to apply these techniques in those, and in the military, because they work better!
There is some interesting stuff published by a variety of US military sources, here are a couple of interesting links:
software.af.mil/wp-content/uploads/2019/12/DoD-Enterprise-DevSecOps-Initiative-Keynote-v1.7.pdf
dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf
Amazing content! While most software engineering channels focus on superfical things like framework x or algorithm y, one can see a deep understand of fundamental concepts and a scientific approach to the way you are explaining things. Kudos!
Thanks
This is a gold mine of truth.
I think you might like to read the story behind the gossamer condor, the first human powered aircraft. Precisely by iterating it succeeded where competitors failed.
Thanks, I remember the Gossamer Condor, I will check that out.
The SpaceX software team has now had two AMA's on Reddit as far as I know. I thought you would speak to what they said about software development directly, as well. Could you?
Question: are the Space X project entirely develop in Agile or just some departments?
In terms of software development my honest answer is that I don't know. I would be quite surprised if they are not though, they are moving very fast and with good quality, but beyond that Tesla are significant implementers of Continuous Delivery for all the software in their cars, and, of course Tesla and SpaceX are both Elon Musk companies. I do plan to do a video in future on the Tesla approach to CD, because they have published a fair bit on it and there is some interesting stuff there.
Thanks for the response!
Just some thoughts/concerns regarding pure Agile in Embedded:
I don't know if continuous delivery, in this case, adds any value because you have to test the software, and I don't think they have recordings from older projects, and these recordings can be adapt for testing this specific product! They will probably test in a 100% synthetic environment, which is not the reality! So maybe it will be a better approach to follow (focus) a "rigid" plan in the early stages of the project (which probably is very complex for certain ECU's) than weekly deliver aspects/features of the software that can not be 100% testable.
Agile makes customers happier, we all know that, but it doesn't mean the code's quality will be better in all instances. Embedded has a different/specific need than PC SW, so at least for some projects (you mention Tesla - especially ADAS projects), a combination between Waterfall and Agile is more suitable than pure Agile/Waterfall!
For embedded, in some specific domains, a pure Agile approach can represent a greater risk, for example:
In an ADAS project where you have 20-30000 CUSTOMER requirements (broad req not refined req), you need VERY knowledgeable feature teams (understanding the whole picture) to prioritize features and consider all the standards/legislation/etc. related to this req when they implement and test the code.
Just do not forget! ECU's purpose in this kind of project is to interact with the environment like a human been, prevent accidents, and save lives.
@@devianceRo Actually the data, for Continuous Delivery at least, says that the quality is significantly higher (see "state of DevOps reports"). Teams often/usually see orders of magnitude reductions in defect counts for example. I do quite a lot of work with teams that have embedded systems as part of their portfolio. I think that the shift is to stop thinking of testing as a "once you are finished with dev" kind of activity and rather an inherent, guiding principle for development. That way we design for testability, which has the knock-on effect of also improving the quality of our designs. This is what I really mean when I speak about "engineering" in the SW context.
Hi Dave, long time no speak. Really appreciating the content on the channel.
Where do you see other related disciplines fitting into "engineering"? I'm thinking business analysts, UX, the idea of lo-fi prototypes, minimum viable products and the like. Obviously our focus as coders is rightly on the deployment pipeline, but there is usually a whole set of work before new ideas make it to developers.
Cheers,
Chris (ex Waters)
Chris, how are things?
My view is that it is about thinking in terms of experimentation. "What is my theory?", "How could I test that theory", "What do I want to learn", "What info do I need to gather to learn it?", "What variables can I eliminate, so that the answers are clearer".
I think that, at this level, practical science (engineering) is pretty generic.
UX is a good example, www.fastcompany.com/1403230/googles-marissa-mayer-assaults-designers-data
Very good Channel Dave.
As a learner I've realized there was a lack of this information you teach on RUclips which I've come to realize isn't good.
Refreshing not to see another "Netflix" or "Twitter" clone app being done!
Glad you like it, thanks
So the NOSTROMO Shirt in one of the previous videos was a hint to a video about Space ships
I see what you are doing here man
Excellent content again!
Thanks
Just a weird question that popped in my head while watching this, what did they use to test the testing software as they developed it?
Great content as always.
I would love to know more about SpaceX's approach to software development.
I know that Tesla run a pretty sophisticated Continuous Delivery approach, I plan to do a video on that at some point. I would imagine that SpaceX do something similar.
Hello Dave, can you make/do you already have a video that explains the shape of your pipeline diagram? It does look circular, but its supposed to be linear (coz you know it is a pipe"line"), I full don't get the lines between the stages, sometimes a stage is drawn at the center of the circle. I know there is reasoning behind it, I just don't understand it. Can you help a viewer please?
The circle is just a way to fit a pipeline into a diagram better. Actually the pipeline is named for "Instruction Pipelines" in Intel processors, as it is a kind of "branch prediction optimisation". Here are a couple of videos that go into a bit more detail...
Pipeline Webinar: ruclips.net/video/ONnwToAH4bU/видео.html
Pipeline Explained: ruclips.net/video/x9l6yw1PFbs/видео.html
I also have a very good training course on the subject 😁
Funny, just found your channel - great, thanks :) - and was about to suggest you to do a video on starship as seemingly the first CD pipeline for rocket design.... Dunno if you just skipped it but Musk cited the rate of build and change with steel vs carbon as a key, if not the primary driver of change, along with cost and temp. perf as you noted. Talks about it in September 2019 starship update.
Yes, I also did a video on Tesla, another of Elon Muscks "CD companies".
ruclips.net/video/ZMWAlPRhiwY/видео.html
@@ContinuousDelivery hey Dave there's a spacex software AMA on Reddit later today, in case you missed it
@@danm6189 Thanks, I will check it out if I can.
Awesome video once again Dave. Love the real world / company focus to help things from being too theoretical. Great approach, super clear and would love to see more like it. What about another video game company that is developing / engineering with modern CI/CD practices?
EPIC's Fortnight could be a good example to look into. (not a fan of the game myself but their ability to churn out new content and features is second to none)
Thanks for the suggestion
@@l_combo I am not sure if Fortnite is the best example because as far as I understand they tend to make somewhat extreme changes each season rather than iterative changes so the experiments they run are not well controlled. This is not a very scientific approach.
In terms of engineering practices, Nintendo proper is probably one of the best game companies. They experiment heavily rather than rely on common practices and conventions and throw out stuff that doesn't work. And their games are some of the best engineered in the business.
This is an interesting definition of engineering, it sort of sounds like you are redefining engineering as science, rather than just calling software development a science. If engineering is the process of applying the scientific method to solve problems (as apposed to the engineering design process), then what is science?
Great content as always
I would like to get behind the "engineers are optimizing for learning" idea. And with SpaceX you are probably right.
But what about engineers that build bridges (or gears, or ..). I would assume, that they simply apply existing knowledge to a problem.
How far away are we from the point that a computer could independently generate the plans for a bridge that would work. (Probably 100 Variations of wich the major could than select one that satisfies his ego the best )
My point: The whole learning thing is only true if you do something new. Most SW projects are that way, and SpaceX stuff is, too. But not all of engineering is.
That kind of is my point, that in SW we are always "doing something new" so SpaceX is a good example for us. In SW the "cost of production" is so low that it may as well be free. That means that we'd be dumb to reproduce stuff that we already have, so we are always, within the context of a development, working on something new. That doesn't mean that no one has ever done it before, but it is ALWAYS at least new to the team working on it.
I think that bridge-building is, in reality, probably less "cookie-cutter" than we SW devs think, but even if it is, that is about production engineering, not design engineering, we are always - ALWAYS in the design-engineering space. So I do think that SpaceX offers some interesting pointers for us.
Software has been in use to support civil engineers for decades. Designing a bridge, or parts and materials for a jet engine, or any other materials engineering endeavour, is prone to involve computer calculations and many iterative simulations. Engineers consider simulations as irreplaceable.
Simply applying rules of thumb is the old way. The very old way.
I thought this was going to be about software engineering at SpaceX, but instead it's using SpaceX's hardware engineering practice as an example of how to do software engineering. The analogy doesn't seem super apt. Does SpaceX actually do its *software* engineering in the way you describe?
Except starship is not production-ready and doesn't pretend to be. So it really argues in favour of Prototyping and against Continuous Delivery if anything. Wouldn't Continuous Delivery advocate iterating on Falcon 9 instead? (which SpaceX has also done)
I see your point, but I see no reason why Starship isn't a CD project too. In fact I can see direct analogies in some of my own work. They built a system, in Falcon 9 (in my case a simple Financial exchange) that worked, but couldn't do all that was needed. Falcon 9s are never going to open up Mars exploration, my exchange wasn't fast enough. So you take your learning from that and start working on somehting that has a better chance of doing what you need.
The next question is what does "production-ready" mean? For the StarHopper it needed to fly 150m up and then land. That was it's version of production. For SN15, which has recently landed successfully, then it's version of "prod-ready" meant that it could fly to 12km and land back on the pad.
It seems to me that "Design Engineering" is always incremental, experimental, in this way, but just because you are iterating doesn't stop you switching tracks when what you learn says "this route won't get you where you want to be".
Thank you again for sharing your deep well of knowledge with us.
Thank you
Great Video!
Great content
Top tier content!
Thanks
Thank you :-)
You are welcome!
Ooh,, right up my alley!
I am just old enough to see men walk on the moon, I have been addicted to space exploration since then.
@@ContinuousDelivery Thanks again, I love the channel.
Who on earth gave this a thumbs down?
🤷♂️ Thanks 🙂
What do you mean by "when was the last time you heard software engineers speaking like this?"? Speaking like what? About steel, temperature and basic physics concepts? I'm a game developer in in my day-to-day routine I have to deal with much more abstract problems to think how to accomplish features while optimizing performance. Not steel, aluminum, carbon - that every normal person can understand, but meshes, vertices, pixels, etc or language related like Arrays vs Lists (performance vs ease of use), etc, etc. We software engineers work on a level of abstraction above everyone else.
No matter what layer of abstraction you are working in you still have to explain why a particular decision makes more sense. I choose X data structure over Y data structure because even though its more expensive in memory its faster. Terms that anyone can understand.
I'm a programmer by trade but I have a Mechanical Engineering degree. Mechanical Engineering uses the same tools as software developer such as vertices, linear algebra, etc. For example how would you model stresses over complex geometry of a part say a car? Ultimately as a mechanical engineer or a game programmer we still have to explain things to people outside of our trade in terms that make sense. Most often in dollars and time :).
Yes exactly!
I think that all too often we miss that important rationale. Quantum physicists don't say "this is really hard, so let's just guess instead", well maybe they do a bit, but the important thing after the guesses is to figure out how to make our decisions more rational.
I was speaking by analogy, when was the last time that you made a decision in software based on measurement rather than guesswork? Do you know the performance characteristics of the data structures and collections that you use? Do you think about the big 'O' number before choosing?
I am not suggesting that you need to know the temperature of your software or its tensile strength but what is the equvalent?
How many bytes per entry does a hashmap add compared to an array? I can tell you the answer for that in the version of Java that I used when building trading systems, because it matters, it matters in terms of the size of the models that you can hold in memory and, maybe more importantly for trading, and maybe for games, it matters in terms of performance. If your hashmap entries take more space that means a higher cost to move them into the CPU, a higher cost to copy them, a higher cost to garbage collect them too, depending on how that works.
These too are only simplistic examples. I think that the important idea is that we should think about what we can, and should, measure and understand in order to work on the basis of knowledge rather than guesses and fashion. That is even more important for software than for rocket engineers, because our stuff is so abstract, maths is pretty abstract too, but that doesn't mean that they give up, we, as an industry, have mostly given up on rational decision-making.
I interpreted this slightly differently to you. Carbon fibre could be the year's fashionable tech that everyone wants on their CV - block chain, rust, kubernetes, event buses, whatever. All good at some things, but often selected because everyone else is doing the same. Steel is good old C++, Java, C#, clean code, etc. No one would get excited about these things, but they get the job done.
Well, I think they did what you'd expect. You start with a guess, "let's use CF cos everyone is raving about the strength to weight ratio", then you start assuming how your guess is probably wrong, and looking at the ways that it may be wrong to see how that starting point plays out. In this case, it was too expensive and not strong enough for its weight at some important operating temperatures.
I think that there is a lot to be said for "boring tech" sometimes, lots of people have experience of it, and so we know the wrinkles. the reason that I highlighted it here, is because I think that analogous decision making is so rare in software.
Even when we do tech bake-offs, we are often extremely subjective in the criteria that we apply. This is one of the reasons that the Stability & Throughput measures from the "Accelerate" book as so important. They give us a bench-mark that we can use. "If I pick this tech, does it make my quality higher (Stability) or my efficiency better (Throughput)?". If if makes them worse, don't do it, if they are the same, only then decide on subjective qualities.
Have you been following the Video Card price inflation due to crypto miners?
Elon Musk should get into that... All he would need to do is figure out a way to get video cards to customers without the dip in supply.
I think he is doing fairly well on his current projects too. 🙂
www.forbes.com/sites/sergeiklebnikov/2021/01/14/elon-musk-is-the-richest-person-in-the-world-again/
Where is this live stream of spacex developing software? If only Elon wasn’t such a clown, that’s why I’d rather invest in the blue origin team.
I didn’t say a “live stream of SpaceX developing software” I was referring to the live stream of SpaceX doing engineering, developing their rockets, in public, on RUclips.