Control structures as in "business logic" is essential complexity to me.
Random spaghetti code and boilerplate isn't, but Brooks' argument is that improving this, while definitely a good thing to strive for, won't result in a huge improvement in productivity, because the major roadblocks lie elsewhere.
I don't think he is arguing against minor wins, either. He just says we must focus on the major ones.
If you go into backend code from the typical place where "backend code" is a thing, it can be derived completely mechanically from the frontend. So all the work that goes into it is accidental, for a start.
Often that relation goes both ways, and the frontend code (that is even more complex) can be derived from the backend too.
That's boilerplate code and I agree it can be completely automated.
I would argue it's a very convenient but minor thing, and that it doesn't truly change the complexity of writing code. It just makes it less dreary. I would also argue it's a win that it can be automated, and I think Brooks would agree!
I don't think he was arguing small wins don't matter.
Boilerplate in itself is not complexity (eg import statements), it’s just tedious and unergonomic. In fact it can reduce complexity, again with example of imports being a better alternative than global symbols.
Coupled boilerplate on the other hand is complexity, where if you change x in front end you also must change corresponding x in backend.
Random spaghetti code and boilerplate isn't, but Brooks' argument is that improving this, while definitely a good thing to strive for, won't result in a huge improvement in productivity, because the major roadblocks lie elsewhere.
I don't think he is arguing against minor wins, either. He just says we must focus on the major ones.