5 ms·

They can in modelling tools.

WJW 6y ago
Do they actually run unit tests over those? I've seen the VR modelers where you can "walk" through the builidng but those didn't really verify whether there was enough room in the walls for piping, light fall, floor strength limits, fire requirements etc. I know at least one department in the Dutch navy was using constraint solvers to design a new submarine class but I haven't heard about a lot about house design. Not a home architect though, so maybe I just haven't kept up to the state of the art there.
- tonyarkles 6y ago
  > do they run unit tests on those My initial glib answer is “no, the engineers are stuck to deal with the bad design afterwards” :) My less glib answer would be that most disciplines of engineering do do modelling and “virtual testing”. I’ve been working on largish drones for about 18 months. Electronics get specced out, circuits get drawn and simulated, currents are estimated and components are specced based on those estimates, etc. On the mechanical side, parts are drawn in CAD, analyzed for proper fit and assemble-ability, FEA is used to determine whether a part is likely to be strong enough for the static and dynamic loads that will be placed on the aircraft, etc. All of this happens, generally, before circuit boards or modules get ordered or before the first chunk of aluminum goes into the CNC. As far as building software goes, I’ve recently had to start digging into DO-178C, and I’m pretty impressed so far. Despite having been through engineering school (EE), I haven’t ever really had to put this level of rigour into practice for software before. It feels slow and somewhat time consuming, but I’m feeling more and more confident that the module I’m working on is going to be pretty damned robust. It’s not a “certification required” unit, but it would be a huge pain in the ass if it failed and couldn’t recover without human intervention; as a result I’m doing more of a “DO-178C lite” with detailed low-level requirements stated explicitly, system architecture drawn out first, sequence diagrams for the complicated event-driven parts, state charts for the different parallel systems, etc.
- hwayne 6y ago
  Yeah, they do. https://www.youtube.com/watch?v=yJW--wNMv1M https://www.youtube.com/watch?v=yJW--wNMv1M
RealityVoid 6y ago
And that's the thing, the code _is_ the blueprint. What is code if not a sufficiently detailed specification?
- tonyarkles 6y ago
  That has, until recently, been my philosophy for a long time. See my sibling comment for context. Another example of where modelling both saved time and helped make a system more reliable: about 6 months ago, I took on a project that involved integrating a Bluetooth-Iridium gateway into an existing app, so that the app could work in areas with no wifi or cell connectivity. There’s a lot of things going on here: the Iridium modem has a limited queue size, transmissions are not instant, connectivity to the constellation fades in and out, Bluetooth randomly disconnects, etc. My gut reaction is to slowly build it out. Start with the low-level BLE stuff and build layers on top. Which I did do to shake out the functionality. But before I went and built the whole thing, I stopped and tried to build a TLA+ model of the system. That modelling was only somewhat successful; based on the constraints applied by each part, I discovered that it would be impossible to make the entire system reliable. What the model did, though, was highlight specific failure cases that would need to be detected and reported to the user. I agree that, in the end, the source code ends up being a detailed and precise specification of what the system does. What I’m realizing more and more though is that putting together more abstract models of the system ahead of time can save a ton of time by forcing you to think through cases that would (in my experience) end up with dirty hacks when they’re discovered after 90% of the code has been written. It’s not the approach required for every project. I still love firing up a Python or Lisp REPL and hacking away. It’s way more fun! But for certain types of software, it’s very much not the appropriate way to work.
  - hwayne 6y ago
    > That modelling was only somewhat successful; based on the constraints applied by each part, I discovered that it would be impossible to make the entire system reliable. "I discovered I can't satisfy all my requirements at once and need to plan my tradeoffs in advance" sounds like a pretty successful modeling result to me!

WJW 6y ago

Do they actually run unit tests over those? I've seen the VR modelers where you can "walk" through the builidng but those didn't really verify whether there was enough room in the walls for piping, light fall, floor strength limits, fire requirements etc. I know at least one department in the Dutch navy was using constraint solvers to design a new submarine class but I haven't heard about a lot about house design. Not a home architect though, so maybe I just haven't kept up to the state of the art there.

tonyarkles 6y ago
> do they run unit tests on those My initial glib answer is “no, the engineers are stuck to deal with the bad design afterwards” :) My less glib answer would be that most disciplines of engineering do do modelling and “virtual testing”. I’ve been working on largish drones for about 18 months. Electronics get specced out, circuits get drawn and simulated, currents are estimated and components are specced based on those estimates, etc. On the mechanical side, parts are drawn in CAD, analyzed for proper fit and assemble-ability, FEA is used to determine whether a part is likely to be strong enough for the static and dynamic loads that will be placed on the aircraft, etc. All of this happens, generally, before circuit boards or modules get ordered or before the first chunk of aluminum goes into the CNC. As far as building software goes, I’ve recently had to start digging into DO-178C, and I’m pretty impressed so far. Despite having been through engineering school (EE), I haven’t ever really had to put this level of rigour into practice for software before. It feels slow and somewhat time consuming, but I’m feeling more and more confident that the module I’m working on is going to be pretty damned robust. It’s not a “certification required” unit, but it would be a huge pain in the ass if it failed and couldn’t recover without human intervention; as a result I’m doing more of a “DO-178C lite” with detailed low-level requirements stated explicitly, system architecture drawn out first, sequence diagrams for the complicated event-driven parts, state charts for the different parallel systems, etc.
hwayne 6y ago
Yeah, they do. https://www.youtube.com/watch?v=yJW--wNMv1M https://www.youtube.com/watch?v=yJW--wNMv1M

RealityVoid 6y ago

And that's the thing, the code _is_ the blueprint. What is code if not a sufficiently detailed specification?

tonyarkles 6y ago
That has, until recently, been my philosophy for a long time. See my sibling comment for context. Another example of where modelling both saved time and helped make a system more reliable: about 6 months ago, I took on a project that involved integrating a Bluetooth-Iridium gateway into an existing app, so that the app could work in areas with no wifi or cell connectivity. There’s a lot of things going on here: the Iridium modem has a limited queue size, transmissions are not instant, connectivity to the constellation fades in and out, Bluetooth randomly disconnects, etc. My gut reaction is to slowly build it out. Start with the low-level BLE stuff and build layers on top. Which I did do to shake out the functionality. But before I went and built the whole thing, I stopped and tried to build a TLA+ model of the system. That modelling was only somewhat successful; based on the constraints applied by each part, I discovered that it would be impossible to make the entire system reliable. What the model did, though, was highlight specific failure cases that would need to be detected and reported to the user. I agree that, in the end, the source code ends up being a detailed and precise specification of what the system does. What I’m realizing more and more though is that putting together more abstract models of the system ahead of time can save a ton of time by forcing you to think through cases that would (in my experience) end up with dirty hacks when they’re discovered after 90% of the code has been written. It’s not the approach required for every project. I still love firing up a Python or Lisp REPL and hacking away. It’s way more fun! But for certain types of software, it’s very much not the appropriate way to work.
- hwayne 6y ago
  > That modelling was only somewhat successful; based on the constraints applied by each part, I discovered that it would be impossible to make the entire system reliable. "I discovered I can't satisfy all my requirements at once and need to plan my tradeoffs in advance" sounds like a pretty successful modeling result to me!