4 ms·
Agile works OK for electronics. I have done it. With quick-turn fab houses, you can do two-week sprints in hardware. You can fix up the circuit with X-acto/b
by markrages 7y ago
Agile works OK for electronics. I have done it.
With quick-turn fab houses, you can do two-week sprints in hardware. You can fix up the circuit with X-acto/bluewire changes, and roll the fixes into the next sprint. Or you can make individual subsystems per sprint.
And with firmware, most software methodologies work with minor changes.
Usually you can get something working in the first sprint, and iterate from there.
- roland35 7y agoYour absolutely right, and with a modular system design it can make it easier to plug in iterations of individual components. But at some point early in the design you need to lay out how the modules will work together, i.e. do we use CAN? 24V power or 48V? All that can be changed as well but at some point it gets complicated! For a simple project all of that can be managed iteratively.
- InternetOfStuff 7y ago> All that can be changed as well but at some point it gets complicated! Not everything has to be changed, that's just a strawman. But not every detail has to be nailed down at the beginning either. The idea behind Agile is to reduce risk. If there is no risk of the bus system changing on you, there's no harm in fixing it right at the beginning. But if there is a chance it might, you'd do well to have systems in place which enable you to react to changes with a minimum (though non-zero, of course) amount of pain.
- aidenn0 7y agoThe same is true with software, unless you suggest that Agile will change the implementation language with every sprint...
- organsnyder 7y agoAll the more reason to use an agile approach! The only reason you would be making those major changes is in the face of new information: a change in requirements, an unforeseen challenge, etc. It's impossible to foresee those all in advance—better to adopt a system that is structured to anticipate them. "Unknown unknowns" are a fact of life, no matter how disciplined we believe we are with our preparation.
- Angostura 7y agoSounds like it could lead to bit if a tech support nightmare though? "Ah, you have hardware version 2.3.1.3 - yes, it does sometimes emit sparks - we fixed that in the version that came out the month after."
- GhettoMaestro 7y agoSomething that emits sparks should not be in the field. It should be recalled/replaced with a safe piece of hardware.
- Angostura 7y agoFeel free to amend 'emits sparks' to read 'has hardware bug X'.
- GhettoMaestro 7y agoWrong. There are hardware bugs that do not manifest as physical safety risks. Physical safety risks are an exceptional class of defects that in most jurisdictions has a legal requirement for the vendor to fix or replace the defective part(s) at their own cost (not to be borne by consumer). Point: SPECTRE/MELTDOWN were not "physical safety risks". Yes you can argue they are security risks, but they didn't physically manifest as a physical safety risk which can lead to severe injury or loss of life.
- Angostura 7y agoI'm not sure what point you are trying to make. I said amend it to make it a hardware fault of your choice, or make those sparks a bit of static.
- GhettoMaestro 7y agoMy point was that a physical safety risk is a special kind of "hardware bug". It is not just another hardware bug, of a different flavor. Your commentary seemed to suggest you were not attaching an appropriate level of mental priority with regards to the severity and risk.