3 ms·

> However, I still think waterfall is the only approach when trying to design a hardware product. You can still use some agile ideas when working in electronic

> However, I still think waterfall is the only approach when trying to design a hardware product. You can still use some agile ideas when working in electronics, thought it might look quite differently than in software. For example, if you are a startup and your plan is to create a super duper wireless speaker with bluetooth, wifi and AI, you could first build a wireless speaker with only bluetooth, and sell that. That way you build experience with producing speakers, sales channels, manufacturing, sourcing etc., and build a customer base. Then you could ask your customer base if they'd prefer wifi or AI in the next model, and iterate accordingly. This is not the same as doing one-week sprints in software, but it does iterate that you can start small, build and sell small, viable products, and work your way up to the intended product.

crimsonalucard 7y ago
This is different. Agile and waterfall seem to be defined over the lifetime of a product. Iterating the concept over several products while doing waterfall on each design sounds like a combination of waterfall and agile. I'll be clever and call this transmogrification "agilefall"
- pipelineist 7y ago
  But that's the thing behind agile: you do nice, quick two-week (or however long your sprint is) waterfalls. These quick loops are really the only difference, and are precisely where the advantage lies. And having as short feedback loops as you can get away with has been sound engineering practice since before software was a thing.
  - crimsonalucard 7y ago
    Who says I can't have a 2 month sprint and gather feedback and do testing in those 2 months? Engineering has always done this and called it waterfall. The difference now is more bureaucracy under agile.
crimsonalucard 7y ago
This is also a good way to build airplanes and bridges.
- aeorgnoieang 7y ago
  I think agile could work just fine even for airplanes and bridges, and I imagine people are already doing it. Building the actual bridge on which people will expect to drive or walk or whatever is probably better thought of as deploying a bridge (design), even if it inevitably also includes some ad-hoc on-the-spot development too. But when developing a new bridge design, it seems extremely valuable to be able to iterate as quickly as possible.
  - crimsonalucard 7y ago
    >I imagine people are already doing it. They did do it. The MAX part of the 737 MAX was basically an agile iteration on top of the existing design. >But when developing a new bridge design, it seems extremely valuable to be able to iterate as quickly as possible. Seems like a new and innovative way to design things. Bridge 2.0. Bridge MAX.
    - Miraste 7y ago
      Move fast and break things!
      - aeorgnoieang 7y ago
        Well, yes, and un-ironically – during the development of a new airplane or bridge design. You'd obviously want a new, experimental, or prototypical design to fail ASAP so you can fix whatever the problem(s) are sooner than later. I'm pretty sure most bridge or airplane failures are either due to mistakes made during building or, probably even more often, failing to maintain (and monitor) its condition. But the whole point of agile is to make, and release, smaller sets of changes at a time precisely so those changes can then be tested or validated more quickly than otherwise. That may – probably is – more difficult with airplanes and bridges versus software so the relevant tradeoffs are different, but the basic point about minimizing the duration of making changes so those changes can be tested sooner seems equally applicable. Let's think about bridges. I'm sure most bridges use a standard design with standard materials – that part then has already been tested and validated. But even at the stage of evaluating a standard bridge design and whether and how it could be built in a specific location, I'd imagine an 'agile' methodology would be better than a 'waterfall' one in terms of testing or validating a tentative plan, i.e. you'd want to address the highest priority risks first, and 'fail fast'. You wouldn't want to create a final proposal if you knew up-front that there was no way to anchor a bridge of a certain design in the designated location.

crimsonalucard 7y ago

This is different. Agile and waterfall seem to be defined over the lifetime of a product. Iterating the concept over several products while doing waterfall on each design sounds like a combination of waterfall and agile. I'll be clever and call this transmogrification "agilefall"

pipelineist 7y ago
But that's the thing behind agile: you do nice, quick two-week (or however long your sprint is) waterfalls. These quick loops are really the only difference, and are precisely where the advantage lies. And having as short feedback loops as you can get away with has been sound engineering practice since before software was a thing.
- crimsonalucard 7y ago
  Who says I can't have a 2 month sprint and gather feedback and do testing in those 2 months? Engineering has always done this and called it waterfall. The difference now is more bureaucracy under agile.

crimsonalucard 7y ago

This is also a good way to build airplanes and bridges.

aeorgnoieang 7y ago
I think agile could work just fine even for airplanes and bridges, and I imagine people are already doing it. Building the actual bridge on which people will expect to drive or walk or whatever is probably better thought of as deploying a bridge (design), even if it inevitably also includes some ad-hoc on-the-spot development too. But when developing a new bridge design, it seems extremely valuable to be able to iterate as quickly as possible.
- crimsonalucard 7y ago
  >I imagine people are already doing it. They did do it. The MAX part of the 737 MAX was basically an agile iteration on top of the existing design. >But when developing a new bridge design, it seems extremely valuable to be able to iterate as quickly as possible. Seems like a new and innovative way to design things. Bridge 2.0. Bridge MAX.
  - Miraste 7y ago
    Move fast and break things!
    - aeorgnoieang 7y ago
      Well, yes, and un-ironically – during the development of a new airplane or bridge design. You'd obviously want a new, experimental, or prototypical design to fail ASAP so you can fix whatever the problem(s) are sooner than later. I'm pretty sure most bridge or airplane failures are either due to mistakes made during building or, probably even more often, failing to maintain (and monitor) its condition. But the whole point of agile is to make, and release, smaller sets of changes at a time precisely so those changes can then be tested or validated more quickly than otherwise. That may – probably is – more difficult with airplanes and bridges versus software so the relevant tradeoffs are different, but the basic point about minimizing the duration of making changes so those changes can be tested sooner seems equally applicable. Let's think about bridges. I'm sure most bridges use a standard design with standard materials – that part then has already been tested and validated. But even at the stage of evaluating a standard bridge design and whether and how it could be built in a specific location, I'd imagine an 'agile' methodology would be better than a 'waterfall' one in terms of testing or validating a tentative plan, i.e. you'd want to address the highest priority risks first, and 'fail fast'. You wouldn't want to create a final proposal if you knew up-front that there was no way to anchor a bridge of a certain design in the designated location.