7 ms·

The quote from the CMU guy about modern Agile and DevOps approaches challenging architectural discipline is a nice way of saying most of us have completely forg

by dmk 6mo ago

The quote from the CMU guy about modern Agile and DevOps approaches challenging architectural discipline is a nice way of saying most of us have completely forgotten how to build deterministic systems. Time-triggered Ethernet with strict frame scheduling feels like it's from a parallel universe compared to how we ship software now.

tayk47999 6mo ago
> “Modern Agile and DevOps approaches prioritize iteration, which can challenge architectural discipline,” Riley explained. “As a result, technical debt accumulates, and maintainability and system resiliency suffer.” Not sure i agree with the premise that "doing agile" implies decision making at odds with architecture: you can still iterate on architecture. Terraform etc make that very easy. Sure, tech debt accumulates naturally as a byproduct, but every team i've been on regularly does dedicated tech debt sprints. I don't think the average CRUD API or app needs "perfect determinism", as long as modifications are idempotent.
- whiskey-one 6mo ago
  In theory, yes you could iterate on architecture and potentially even come up with better one with agile approach. In practice, so many aspects follow from it that it’s not practical to iterate with today’s tools.
- crabbone 6mo ago
  Agile is like communism. Whenever something bad happens to people who practice agile, the explanation is that they did agile wrong, had they being doing the true agile, the problem would've been totally avoided. In reality, agile doesn't mean anything. Anyone can claim to do agile. Anyone can be blamed for only pretending to do agile. There's no yardstick. But it's also easy to understand what the author was trying to say, if we don't try to defend or blame a particular fashionable ideology. I've worked on projects that required high quality of code and product reliability and those that had no such requirement. There is, indeed, a very big difference in approach to the development process. Things that are often associated with agile and DevOps are bad for developing high-quality reliable programs. Here's why: The development process before DevOps looked like this: 1. Planning 2. Programming 3. QA 4. If QA found problems, goto 2 5. Release The "smart" idea behind DevOps, or, as it used to be called at the time "shift left" was to start QA before the whole of programming was done, in parallel with the development process, so that the testers wouldn't be idling for a year waiting for the developers to deliver the product to testers and the developers would have faster feedback to the changes they make. Iterating on this idea was the concept of "continuous delivery" (and that's where DevOps came into play: they are the ones, fundamentally, responsible to make this happen). Continuous delivery observed that since developers are getting feedback sooner in the development process, the release, too, may be "shifted left", thus starting the marketing and sales earlier. Back in those days, however, it was common to expect that testers will be conducting a kind of a double-blindfolded experiment. I.e. testers weren't supposed to know the ins and outs of the code intentionally, s.t. they don't, inadvertently, side with the developers on whatever issues they discover. Something that today, perhaps, would've been called "black-box testing". This became impossible with CD because testers would be incrementally exposed to the decisions governing the internal workings of the product. Another aspect of the more rigorous testing is the "mileage". Critical systems, normally, aren't released w/o being run intensively for a very long time, typically orders of magnitude longer than the single QA cycle (let's say, the QA gets a day of computer time to run their tests, then the mileage needs to be a month or so). This is a very inconvenient time for development, as feature freeze and code freeze are still in effect, so the coding can only happen in the next version of the product (provided it's even planned). But, the incremental approach used by CD managed to sell a lie that says that "we've ran the program for a substantial amount of time during all the increments we've made so far, therefore we don't need to collect more mileage". This, of course, overlooks the fact that changes in the program don't contribute proportionally to the program's quality or performance. In other words, what I'm trying to say is that agile or DevOps practices allowed to make the development process cheaper by making it faster while still maintaining some degree of quality control, however they are inadequate for products with high quality requirements because they don't address the worst case scenarios.
ramraj07 6mo ago
I take the opposite message from that line - out of touch teams working on something so over budget and so overdue, and so bureaucratic, and with such an insanely poor history of success, and they talk as if they have cured cancer. This is the equivalent of Altavista touting how amazing their custom server racks are when Google just starts up on a rack of naked motherboards and eats their lunch and then the world. Lets at least wait till the capsule comes back safely before touting how much better they are than "DevOps" teams running websites, apparently a comparison that's somehow relevant here to stoke egos.
- danhon 6mo ago
  You mean like this? "With limited funds, Google founders Larry Page and Sergey Brin initially deployed this system of inexpensive, interconnected PCs to process many thousands of search requests per second from Google users. This hardware system reflected the Google search algorithm itself, which is based on tolerating multiple computer failures and optimizing around them. This production server was one of about thirty such racks in the first Google data center. Even though many of the installed PCs never worked and were difficult to repair, these racks provided Google with its first large-scale computing system and allowed the company to grow quickly and at minimal cost." https://blog.codinghorror.com/building-a-computer-the-google-way/ https://blog.codinghorror.com/building-a-computer-the-google...
  - 1970-01-01 6mo ago
    Google then had complete regret not doing this with ECC RAM: https://news.ycombinator.com/item?id=14206811 https://news.ycombinator.com/item?id=14206811
    - ramraj07 6mo ago
      It got them to where they need to be to then worry about ECC. This is like the dudes who deploy their blog on kubernetes just in case it hits front page of new york times or something.
      - 6mo ago
arduanika 6mo ago
You could even say that part of the value of Artemis is that we're remembering how to do some very hard things, including the software side. This is something that you can't fake. In a world where one of the more plausible threats of AI is the atrophy of real human skills -- the goose that lays the golden eggs that trains the models -- this is a software feat where I'd claim you couldn't rely on vibe code, at least not fully. That alone is worth my tax dollars.
- randomNumber7 6mo ago
  Don’t count your chickens before they hatch.
  - arduanika 6mo ago
    I'm not sure you really understood my comment. A large portion of the kind of value I'm talking about comes from attempting the hard thing. If these chickens do not hatch that will be tragic, but we will still have learned something from it. In some ways, we will have learned even more, by getting taught about what we don't know. Anyway, let's all hope for a safe landing tonight.
mvkel 6mo ago
If you look at code as art, where its value is a measure of the effort it takes to make, sure.
- couchand 6mo ago
  If your implication is that stencil art does not take effort then perhaps you may not fully appreciate Banksy. Works like Gaza Kitty or Flower Thrower don’t just appear haphazardly without effort.
- BobbyTables2 6mo ago
  In that case, our test infrastructure belongs in the Louvre…
- stodor89 6mo ago
  Or if you're building something important, like a spaceship.
iknowstuff 6mo ago
Tesla’s Cybertruck uses that in its ethernet as well!
- carefree-bob 6mo ago
  All the ADAS automotive systems use this, there are several startups in this space as well, such as Ethernovia.
  - 21asdffdsa12 6mo ago
    All thanks to twisted pair https://de.wikipedia.org/wiki/BroadR-Reach https://de.wikipedia.org/wiki/BroadR-Reach
dyauspitr 6mo ago
Agile is not meant to make solid, robust products. It’s so you can make product fragments/iterations quickly, with okay quality and out to the customer asap to maximize profits.
- nickff 6mo ago
  “Agile” doesn’t mean that you release the first iteration, it’s just a methodology that emphasizes short iteration loops. You can definitely develop reliable real-time systems with Agile.
  - kermatt 6mo ago
    > “Agile” doesn’t mean that you release the first iteration Someone needs to inform the management of the last three companies I worked for about this.
    - t43562 6mo ago
      Management understand it less than anyone else does.
  - tomasGiden 6mo ago
    I would differentiate between iterative development and incremental development. Incremental development is like panting a picture line by line like a printer where you add new pieces to the final result without affecting old pieces. Iterative is where you do the big brush strokes first and then add more and more detail dependent on what to learn from each previous brush strokes. You can also stop at any time when you think that the final result is good enough. If you are making a new type of system and don’t know what issues will come up and what customers will value (highly complex environment) iterative is the thing to do. But if you have a very predictable environment and you are implementing a standard or a very well specified system (van be highly complicated yet not very complex), you might as will do incremental development. Roughly speaking though as there is of course no perfect specification which is not the final implementation so there are always learnings so there is always some iterative parts of it.
  - 6mo ago
vasco 6mo ago
It's not like the approach they took is any different. Just slapped 8x the number of computers on it for calculating the same thing and wait to see if they disagree. Not the pinnacle of engineering. The equivalent of throwing money at the problem.
- MikeTheGreat 6mo ago
  What happens when they don't?
  - vasco 6mo ago
    If you have a point to make, make it.
    - MikeTheGreat 6mo ago
      What my question is hinting at is that there's actually some really interesting engineering around resolving what happens when the systems disagree. Things like Paxos and Raft help make this much more tractable for mere mortals (like myself); the logic and reasoning behind them are cool and interesting.
      - vasco 6mo ago
        [flagged]
      - FabHK 6mo ago
        Though here the consensus algorithm seems totally different from Paxos/Raft. Rather it's a binary tree, where every non-leaf node compares the (non-silent) inputs from the leaf, and if they're different, it falls silent, else propagates the (identical) results up. Or something something.
      - HeyLaughingBoy 6mo ago
        There really is. We designed a redundant system (software, hardware and mechanisms) a couple years ago. And the problems around figuring out who's in control and how to keep things synchronized across a number of potential failure modes gets really hairy. Sadly, the project was cancelled before we could complete the implementation.
carefree-bob 6mo ago
During the time of the first Apollo missions, a dominant portion of computing research was funded by the defense department and related arms of government, making this type of deterministic and WCET (worst case execution time) a dominant computing paradigm. Now that we have a huge free market for things like online shopping and social media, this is a bit of a neglected field and suffers from poor investment and mindshare, but I think it's still a fascinating field with some really interesting algorithms -- check out the work of Frank Mueller or Johann Blieberger.
- therobots927 6mo ago
  Contrary to propaganda from the likes of Ludwig von Mises, the free market is not some kind of optimal solution to all of our problems. And it certainly does not produce excellent software.
  - psd1 6mo ago
    I can't think of a time when I've found an absolutist position useful or intelligent, in any field. Free-market absolutism is as stupid as totalitarianism. The content of economics papers does not need to be evaluated to discard an extreme position, one need merely say "there are more things in earth and heaven than are dreamed of in your philosophies"
    - staplers 6mo ago
      Great point, if the only constant is change, then philosophy should follow (or lead).
  - nairboon 6mo ago
    Propaganda is quite a strong term to describe the works of an economist. If one wants to debate the ideas of von Mises, it'd be useful to consider the Zeitgeist at that time. Von Mises preferred free markets in contrast to the planned economy of the communists. Partly because the latter has difficulties in proper resource allocation and pricing. Note that this was decades before we had working digital computers and digital communication systems, which, at least in theory, change the feasibility of a planned economy. Also, the last time I checked, the US government produced its goods and services using the free market. The government contractors (private enterprises) are usually tasked with building stuff, compared with the government itself in a non-free, purely planned economy (if you refer to von Mises). I assume that you originally meant to refer to the idea that without government intervention (funding for deep R&D), the free market itself would probably not have produced things like the internet or the moon landing (or at least not within the observed time span). That is, however,a rather interesting idea.
pjmlp 6mo ago
As 70's child that was there when the whole agile took over, and systems engineer got rebranded as devops, I fully agree with them. Add TDD, XP and mob programming as well. While in some ways better than pure waterfall, most companies never adopted them fully, while in some scenarios they are more fit to a Silicon Valley TV show than anything else.
ggm 6mo ago
Time triggered Ethernet is part of aircraft certified data bus and has a deep, decades long history. I believe INRIA did work on this, feeding Airbus maybe. It makes perfect sense when you can design for it. An aircraft is a bounded problem space of inputs and outputs which can have deterministic required minima and then you can build for it, and hopefully even have headroom for extras. Ethernet is such a misnomer for something which now is innately about a switching core ASIC or special purpose hardware, and direct (optical even) connects to a device. I'm sure there are also buses, dual redundant, master/slave failover, you name it. And given it's air or space probably a clockwork backup with a squirrel.
- Arch-TK 6mo ago
  A real squirrel would need acorns, I would assume it's a clockwork squirrel too.
  - sqrrl-io 6mo ago
    A software squirrel, maybe? https://sqrrl.io https://sqrrl.io :-)
- 21asdffdsa12 6mo ago
  Aircraft also have software and components, that form a "working" proclaimed eco-system in lockstep- a baseline. This is why there are paper "additions" on bug discovery until the bug is patched and the whole ecosystem of devices is lifted to the next "baseline".
deleted 6mo ago
[deleted]
guenthert 6mo ago
I think he refers to SpaceWire https://en.wikipedia.org/wiki/SpaceWire https://en.wikipedia.org/wiki/SpaceWire.
anymouse123456 6mo ago
Some of us still work on embedded systems with real-time guarantees. Believe it or not, at least some of those modern practices (unit testing, CI, etc) do make a big (positive) difference there.
- cpgxiii 6mo ago
  The depressing part is that these "modern practices" were essentially invented in the 1960s by defense and aerospace projects like the NTDS, LLRV/LLTV, and Digital Fly-by-Wire to produce safety-critical software, and the rest of the software industry simply ignored them until the last couple of decades.
globnomulous 6mo ago
Microsoft fired all QA people ten or fifteen years ago. I'd imagine it's a similar a story: boxed software needed much higher guarantees of correctness. Digital deliver leaves much more room for error, because it leaves room for easier, cheaper fixes.

by dmk 6mo ago

tayk47999 6mo ago

> “Modern Agile and DevOps approaches prioritize iteration, which can challenge architectural discipline,” Riley explained. “As a result, technical debt accumulates, and maintainability and system resiliency suffer.” Not sure i agree with the premise that "doing agile" implies decision making at odds with architecture: you can still iterate on architecture. Terraform etc make that very easy. Sure, tech debt accumulates naturally as a byproduct, but every team i've been on regularly does dedicated tech debt sprints. I don't think the average CRUD API or app needs "perfect determinism", as long as modifications are idempotent.

whiskey-one 6mo ago
In theory, yes you could iterate on architecture and potentially even come up with better one with agile approach. In practice, so many aspects follow from it that it’s not practical to iterate with today’s tools.
crabbone 6mo ago
Agile is like communism. Whenever something bad happens to people who practice agile, the explanation is that they did agile wrong, had they being doing the true agile, the problem would've been totally avoided. In reality, agile doesn't mean anything. Anyone can claim to do agile. Anyone can be blamed for only pretending to do agile. There's no yardstick. But it's also easy to understand what the author was trying to say, if we don't try to defend or blame a particular fashionable ideology. I've worked on projects that required high quality of code and product reliability and those that had no such requirement. There is, indeed, a very big difference in approach to the development process. Things that are often associated with agile and DevOps are bad for developing high-quality reliable programs. Here's why: The development process before DevOps looked like this: 1. Planning 2. Programming 3. QA 4. If QA found problems, goto 2 5. Release The "smart" idea behind DevOps, or, as it used to be called at the time "shift left" was to start QA before the whole of programming was done, in parallel with the development process, so that the testers wouldn't be idling for a year waiting for the developers to deliver the product to testers and the developers would have faster feedback to the changes they make. Iterating on this idea was the concept of "continuous delivery" (and that's where DevOps came into play: they are the ones, fundamentally, responsible to make this happen). Continuous delivery observed that since developers are getting feedback sooner in the development process, the release, too, may be "shifted left", thus starting the marketing and sales earlier. Back in those days, however, it was common to expect that testers will be conducting a kind of a double-blindfolded experiment. I.e. testers weren't supposed to know the ins and outs of the code intentionally, s.t. they don't, inadvertently, side with the developers on whatever issues they discover. Something that today, perhaps, would've been called "black-box testing". This became impossible with CD because testers would be incrementally exposed to the decisions governing the internal workings of the product. Another aspect of the more rigorous testing is the "mileage". Critical systems, normally, aren't released w/o being run intensively for a very long time, typically orders of magnitude longer than the single QA cycle (let's say, the QA gets a day of computer time to run their tests, then the mileage needs to be a month or so). This is a very inconvenient time for development, as feature freeze and code freeze are still in effect, so the coding can only happen in the next version of the product (provided it's even planned). But, the incremental approach used by CD managed to sell a lie that says that "we've ran the program for a substantial amount of time during all the increments we've made so far, therefore we don't need to collect more mileage". This, of course, overlooks the fact that changes in the program don't contribute proportionally to the program's quality or performance. In other words, what I'm trying to say is that agile or DevOps practices allowed to make the development process cheaper by making it faster while still maintaining some degree of quality control, however they are inadequate for products with high quality requirements because they don't address the worst case scenarios.

ramraj07 6mo ago

I take the opposite message from that line - out of touch teams working on something so over budget and so overdue, and so bureaucratic, and with such an insanely poor history of success, and they talk as if they have cured cancer. This is the equivalent of Altavista touting how amazing their custom server racks are when Google just starts up on a rack of naked motherboards and eats their lunch and then the world. Lets at least wait till the capsule comes back safely before touting how much better they are than "DevOps" teams running websites, apparently a comparison that's somehow relevant here to stoke egos.

danhon 6mo ago
You mean like this? "With limited funds, Google founders Larry Page and Sergey Brin initially deployed this system of inexpensive, interconnected PCs to process many thousands of search requests per second from Google users. This hardware system reflected the Google search algorithm itself, which is based on tolerating multiple computer failures and optimizing around them. This production server was one of about thirty such racks in the first Google data center. Even though many of the installed PCs never worked and were difficult to repair, these racks provided Google with its first large-scale computing system and allowed the company to grow quickly and at minimal cost." https://blog.codinghorror.com/building-a-computer-the-google-way/ https://blog.codinghorror.com/building-a-computer-the-google...
- 1970-01-01 6mo ago
  Google then had complete regret not doing this with ECC RAM: https://news.ycombinator.com/item?id=14206811 https://news.ycombinator.com/item?id=14206811
  - ramraj07 6mo ago
    It got them to where they need to be to then worry about ECC. This is like the dudes who deploy their blog on kubernetes just in case it hits front page of new york times or something.
    - 6mo ago

arduanika 6mo ago

You could even say that part of the value of Artemis is that we're remembering how to do some very hard things, including the software side. This is something that you can't fake. In a world where one of the more plausible threats of AI is the atrophy of real human skills -- the goose that lays the golden eggs that trains the models -- this is a software feat where I'd claim you couldn't rely on vibe code, at least not fully. That alone is worth my tax dollars.

randomNumber7 6mo ago
Don’t count your chickens before they hatch.
- arduanika 6mo ago
  I'm not sure you really understood my comment. A large portion of the kind of value I'm talking about comes from attempting the hard thing. If these chickens do not hatch that will be tragic, but we will still have learned something from it. In some ways, we will have learned even more, by getting taught about what we don't know. Anyway, let's all hope for a safe landing tonight.

mvkel 6mo ago

If you look at code as art, where its value is a measure of the effort it takes to make, sure.

couchand 6mo ago
If your implication is that stencil art does not take effort then perhaps you may not fully appreciate Banksy. Works like Gaza Kitty or Flower Thrower don’t just appear haphazardly without effort.
BobbyTables2 6mo ago
In that case, our test infrastructure belongs in the Louvre…
stodor89 6mo ago
Or if you're building something important, like a spaceship.

iknowstuff 6mo ago

Tesla’s Cybertruck uses that in its ethernet as well!

carefree-bob 6mo ago
All the ADAS automotive systems use this, there are several startups in this space as well, such as Ethernovia.
- 21asdffdsa12 6mo ago
  All thanks to twisted pair https://de.wikipedia.org/wiki/BroadR-Reach https://de.wikipedia.org/wiki/BroadR-Reach

dyauspitr 6mo ago

Agile is not meant to make solid, robust products. It’s so you can make product fragments/iterations quickly, with okay quality and out to the customer asap to maximize profits.

nickff 6mo ago
“Agile” doesn’t mean that you release the first iteration, it’s just a methodology that emphasizes short iteration loops. You can definitely develop reliable real-time systems with Agile.
- kermatt 6mo ago
  > “Agile” doesn’t mean that you release the first iteration Someone needs to inform the management of the last three companies I worked for about this.
  - t43562 6mo ago
    Management understand it less than anyone else does.
- tomasGiden 6mo ago
  I would differentiate between iterative development and incremental development. Incremental development is like panting a picture line by line like a printer where you add new pieces to the final result without affecting old pieces. Iterative is where you do the big brush strokes first and then add more and more detail dependent on what to learn from each previous brush strokes. You can also stop at any time when you think that the final result is good enough. If you are making a new type of system and don’t know what issues will come up and what customers will value (highly complex environment) iterative is the thing to do. But if you have a very predictable environment and you are implementing a standard or a very well specified system (van be highly complicated yet not very complex), you might as will do incremental development. Roughly speaking though as there is of course no perfect specification which is not the final implementation so there are always learnings so there is always some iterative parts of it.
- 6mo ago

vasco 6mo ago

It's not like the approach they took is any different. Just slapped 8x the number of computers on it for calculating the same thing and wait to see if they disagree. Not the pinnacle of engineering. The equivalent of throwing money at the problem.

MikeTheGreat 6mo ago
What happens when they don't?
- vasco 6mo ago
  If you have a point to make, make it.
  - MikeTheGreat 6mo ago
    What my question is hinting at is that there's actually some really interesting engineering around resolving what happens when the systems disagree. Things like Paxos and Raft help make this much more tractable for mere mortals (like myself); the logic and reasoning behind them are cool and interesting.
    - vasco 6mo ago
      [flagged]
    - FabHK 6mo ago
      Though here the consensus algorithm seems totally different from Paxos/Raft. Rather it's a binary tree, where every non-leaf node compares the (non-silent) inputs from the leaf, and if they're different, it falls silent, else propagates the (identical) results up. Or something something.
    - HeyLaughingBoy 6mo ago
      There really is. We designed a redundant system (software, hardware and mechanisms) a couple years ago. And the problems around figuring out who's in control and how to keep things synchronized across a number of potential failure modes gets really hairy. Sadly, the project was cancelled before we could complete the implementation.

carefree-bob 6mo ago

During the time of the first Apollo missions, a dominant portion of computing research was funded by the defense department and related arms of government, making this type of deterministic and WCET (worst case execution time) a dominant computing paradigm. Now that we have a huge free market for things like online shopping and social media, this is a bit of a neglected field and suffers from poor investment and mindshare, but I think it's still a fascinating field with some really interesting algorithms -- check out the work of Frank Mueller or Johann Blieberger.

therobots927 6mo ago
Contrary to propaganda from the likes of Ludwig von Mises, the free market is not some kind of optimal solution to all of our problems. And it certainly does not produce excellent software.
- psd1 6mo ago
  I can't think of a time when I've found an absolutist position useful or intelligent, in any field. Free-market absolutism is as stupid as totalitarianism. The content of economics papers does not need to be evaluated to discard an extreme position, one need merely say "there are more things in earth and heaven than are dreamed of in your philosophies"
  - staplers 6mo ago
    Great point, if the only constant is change, then philosophy should follow (or lead).
- nairboon 6mo ago
  Propaganda is quite a strong term to describe the works of an economist. If one wants to debate the ideas of von Mises, it'd be useful to consider the Zeitgeist at that time. Von Mises preferred free markets in contrast to the planned economy of the communists. Partly because the latter has difficulties in proper resource allocation and pricing. Note that this was decades before we had working digital computers and digital communication systems, which, at least in theory, change the feasibility of a planned economy. Also, the last time I checked, the US government produced its goods and services using the free market. The government contractors (private enterprises) are usually tasked with building stuff, compared with the government itself in a non-free, purely planned economy (if you refer to von Mises). I assume that you originally meant to refer to the idea that without government intervention (funding for deep R&D), the free market itself would probably not have produced things like the internet or the moon landing (or at least not within the observed time span). That is, however,a rather interesting idea.

pjmlp 6mo ago

As 70's child that was there when the whole agile took over, and systems engineer got rebranded as devops, I fully agree with them. Add TDD, XP and mob programming as well. While in some ways better than pure waterfall, most companies never adopted them fully, while in some scenarios they are more fit to a Silicon Valley TV show than anything else.

ggm 6mo ago

Time triggered Ethernet is part of aircraft certified data bus and has a deep, decades long history. I believe INRIA did work on this, feeding Airbus maybe. It makes perfect sense when you can design for it. An aircraft is a bounded problem space of inputs and outputs which can have deterministic required minima and then you can build for it, and hopefully even have headroom for extras. Ethernet is such a misnomer for something which now is innately about a switching core ASIC or special purpose hardware, and direct (optical even) connects to a device. I'm sure there are also buses, dual redundant, master/slave failover, you name it. And given it's air or space probably a clockwork backup with a squirrel.

Arch-TK 6mo ago
A real squirrel would need acorns, I would assume it's a clockwork squirrel too.
- sqrrl-io 6mo ago
  A software squirrel, maybe? https://sqrrl.io https://sqrrl.io :-)
21asdffdsa12 6mo ago
Aircraft also have software and components, that form a "working" proclaimed eco-system in lockstep- a baseline. This is why there are paper "additions" on bug discovery until the bug is patched and the whole ecosystem of devices is lifted to the next "baseline".

deleted 6mo ago

[deleted]

guenthert 6mo ago

I think he refers to SpaceWire https://en.wikipedia.org/wiki/SpaceWire https://en.wikipedia.org/wiki/SpaceWire.

anymouse123456 6mo ago

Some of us still work on embedded systems with real-time guarantees. Believe it or not, at least some of those modern practices (unit testing, CI, etc) do make a big (positive) difference there.

cpgxiii 6mo ago
The depressing part is that these "modern practices" were essentially invented in the 1960s by defense and aerospace projects like the NTDS, LLRV/LLTV, and Digital Fly-by-Wire to produce safety-critical software, and the rest of the software industry simply ignored them until the last couple of decades.

globnomulous 6mo ago

Microsoft fired all QA people ten or fifteen years ago. I'd imagine it's a similar a story: boxed software needed much higher guarantees of correctness. Digital deliver leaves much more room for error, because it leaves room for easier, cheaper fixes.