Hehe. I thought that doing more assembly than the previous curriculum had in it was important and I added more emphasis on doing assembly labs. In a later year, I also added some practical emphasis on floating point details, as well. I sure "heard" about it from many students. It was as though I was a bad teacher telling them about things they "would never use." :)
They didn't have to (the forms were 'check-off' types of things) and I didn't get to read the details (if any were added) as these forms were sent to management through a different channel. I would hear about the results more abstractly in a 1:1 meeting with the department chair.
Basically, the question in part turned on what you decide are the real teaching priorities. This class was a 200 level 'computer architecture' course (2nd year) and the usual background from the prior year was some glancing familiarity with C or C++, with a few small projects done, and some general classes on "what's a computer?" I felt that good programmers need some serious hands-on with assembly programming to deepen the abstract theory I also taught.
Now that I'm thinking of this, I also took some flak for another choice I felt was important for a 300 level course on operating systems and concurrent programming. Part of this course was just understanding the obvious terms and concepts, such as deadlock and methods to mitigate it, etc. But I also felt that part of understanding operating systems involved details of what program model these operating systems expect to manage -- code sections, constant data sections, initialized data sections, uninitialized data sections, heap and stack, etc., and how these are arranged and organized for reasonable management of an operating system and how these can be seen in light of threads, processes, tasks, and so on. And I expected them to be able to hand compile a simple C function, in 10-15 minutes when asked, because it's also important to understand how compilers work towards these program models, as well. What's a function prologue or an epilogue? How are local instances efficiently managed? What's a stack frame or activation record and why? What's a thunk or coroutine?
Similarly to using assembly to help deepen an understanding of theory, though lab and practical experience, so it is also that knowing the specific details of stacks and activation records and memory classifications and how they are used in operating systems helps to deepen the general operating system theory. Being exposed to exact details is important. I thought that learning some concrete examples were also important and that they should be able to go from concept to concrete implementation and from concrete example to general theory, back and forth freely. That the mental concepts and the practical details would be fluently understood.
Some felt this was too much to ask. Learning the terms and being able to provide dictionary definitions and, just maybe, being able to program a simulation (as a semi-final for the course) to show a 'deadlock' or a simple scheduling algorithm choice (which only takes a few hours to do) is enough, they believed.
Oh, well. Not in my course.
Jon