[zephen]

Nothing I have read by Kent Beck has ever suggested that he would be useful in a chip company, where lots of people toil for a long period of time in order to produce something that no customer can possibly see until it's finished, and that must be sold in quantities of millions in order to make money.

[fmbb]

Well he makes software and writes about software development doesn’t he?

Hardware has some hard limitations. The reason software was even invented at all was precisely to escape those limitations.

[zephen]

> Well he makes software and writes about software development doesn’t he? Hardware has some hard limitations.

Right.

> The reason software was even invented at all was precisely to escape those limitations.

But the methods which are useful for hardware are also often useful for software. Most of the useful parts of agile were already practiced well before that was a name for anything. And the demonization of the straw-man version of waterfall in order to sell more agile consulting has led to some serious misconceptions of what waterfall really is and what it is really capable of and useful for.

The initial impetus for what became known as TDD was software maintenance, and it makes sense there.

But most TDD practitioners are nowhere near as good at real testing as the waterfall test practitioners who understand that a single missed testcase could delay a $10 million project by six months.

And this is why, even in the realm of software you still see serious efforts for aviation and nuclear power plants, and other things with real-world consequences, using more traditional methods.

[toast0]

> no customer can possibly see until it's finished

I'm sure lots of chip companies don't share their work in progress, but it's not impossible. Sharing simulations and prototypes and engineering samples can and does happen. You've typically got to be a big customer, of course.

But yes, insights for an industry with relatively small costs for change don't apply easily to an industry with large costs for change, and often vice versa.

[zephen]

> You've typically got to be a big customer, of course.

Yes, if you're a big enough customer, you might essentially be part of the design team.

> Sharing simulations and prototypes and engineering samples can and does happen.

Simulations aren't the thing. They don't go fast enough to solve anybody's problem. To your point, if a customer is part of the design team, then yes, they can, at that point, help to debug, or possibly even get started on their own dependent designs. (Part of the shift-left I talked about in another comment.)

I'm not sure what you mean by "prototypes" but "engineering samples" are essentially the finished product, done after all the work I described.

Yes, they may have bugs (or they might just not have passed validation and ESD testing yet), but that doesn't alter the fact that a waterfall effort happened before they were delivered.

> But yes, insights for an industry with relatively small costs for change don't apply easily to an industry with large costs for change, and often vice versa.

The problem with indiscriminate use of agile is that, while, yes, the software industry has relatively small costs for change, it has traditionally had huge costs for the initial delivery, and many agile proponents don't properly segregate those two cases.

If LLMs live up to their apparent promise, then, of course, the equations around the huge costs for the initial delivery could change dramatically.

Of course, the same LLM promise means that the strict definition of TDD (tests written first) is also irrelevant, and perhaps even counterproductive.

[marifjeren]

Interesting. How do chip companies plan such projects? Do they use agile, waterfall, or some other non-software-industry frameworks?

[ajb]

They (or at least some of them) use waterfall - the real waterfall, not the bogeyman invented by agile consultants.

[zephen]

(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.