How do you figure? Why should my boss care about unit test frameworks and the relative merits of various TDD strategies. If he has some useful advice from previous projects then great. But otherwise, as long has we aren't having major problems, I don't expect him to interfere with those sorts of decisions. And if we are having major problems I expect him to sit the relevant people down and go "look, we're having too many regression bugs. Whatever you are doing with regards to testing isn't working, so let's come up with something better".
It's not about specific unit test frameworks or TDD strategies. It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development".
It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development".
Even if your boss has manged to get to today without even hearing about these concepts, hopefully there are other people on the team that have. And those people will decide on a testing strategy for the project. If your boss understand the details of that decision or not is isn't that important. What's important is that he lets the best people in room make the decision. Now if your boss decides to override and ignore those people, then that can be a problem, but that is problem due to a lack of managerial and people skills, not a problem due to a lack of technical skills.
That's cute.
Too bad when the project timeline doesn't fit, the teams themselves don't fit, etc. etc. Yeah, team members can decide all they want when they don't have any resources to work with, because the primary strategic decisions didn't account for the workflows people had in mind. And yes, I've seen that happen to otherwise great managers (who took the blame and readily admitted their lack of experience with the (then) new techniques and accommodate planning accordingly - but by then it was rather late in the project...).
Of course, those cases are getting rare, but remember, we're talking about the statement "I think the fundamental principles of software engineering haven't changed a whole lot since [the 80's]".
