3 ms·
Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?
by marifjeren 3mo ago
Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?
- ajb 3mo agoThey (or at least some of them) use waterfall - the real waterfall, not the bogeyman invented by agile consultants.
- andrekandre 3mo ago[dead]
- zephen 3mo ago(Some) chip companies have jumped on the agile bandwagon for (some) tasks. It's always interesting to read about some chip company or another making some agile move, when the reality is that they were already doing about as many agile things as possible before agile was a thing. (For example, a management commitment to "shift left" when they have always been about significant up-front testing and feedback.) In many, if not most, cases, the testing software is so huge that at least some of it needs to be tested itself. That can certainly benefit from agile. But the overall process more resembles traditional waterfall. You have several definite final endpoints, and although you can make subsequent changes, those are expensive. Also, you have a silicon budget, and a pin budget, and a heat and power budget. At the end of the day, you are producing something physical with real-world physical constraints that (a) cost real money, and (b) can't be altered by just telling your customer to add more RAM or a bigger processor. Also, in general, although designers will write their own little unit tests for a few things, it is best practice to insure that the real tests are performed by internal organizations that are different than the organization the designer is in. I think that subconsciously, he truism that it is easier to work with and reason about a system that is already working, and to keep it working, than to get it working at all to begin with, drives a lot of the methodology. The designer might focus on tests to insure that things work well enough to see some results, so things can be hooked up and system tests performed earlier. In one sense, this is a shift left -- the validation people and the people writing software for the chip can get started sooner than they would have otherwise, even if it's a bit frustrating because not everything works off the bat. But the real torture tests are typically written by the dedicated verification and validation teams. Those are really different skills than design.
- marcosdumay 3mo agoJust to point, but shifting left isn't agile at all. In fact, it's slightly against development agility. It's just a good engineering practice, that is more than useful enough to compensate for any loss of agility it may cause.
- zephen 3mo agoOn the one hand, I agree. On the other hand, like a lot of other good ideas, the agile community has claimed this. A quick google will show that many claim it is a "core agile idea."
- dpark 3mo agoIt’s absolutely an agile idea. The core of agile development is the ability to iterate quickly. Shift left for certain things enables the cycle to shorten and accelerate iteration.
- zephen 3mo agoThe useful core idea of "shift left" is early collaboration between development and various testing functions. But, again, that was being done in many organizations (and for sure, in most successful chip companies) well before anything was ever labeled agile.
- dpark 3mo agoI agree that it was done by many organizations before “agile” but that’s true of all agile practices. Agile is a philosophy and a collection of tools. None of the tools are new though.
- zephen 3mo ago> that’s true of all agile practices Which is what, honestly, makes the term essentially meaningless. To the extent that parts of agile are and have always been "best practices" we already had a term for those.