He states pretty explicitly that he doesn't feel he has an intuitive understanding of hardware's performance quirks right in that section. Why should you then be surprised?
Because this is a guy who's supposed to be an authority on software engineering & reading something like that makes me wonder how on earth he ever came to be an authority. It's a bit like someone convincing you they're a racing driver then admitting they're not really sure what the clutch does. (Yes that's hyperbole, but still...)
To abuse your analogy there are many fast drivers that have little to know mechanical knowledge.
You seem to be under the impression that to be an authority one must have comprehensive and detailed knowledge, particularly in areas you care about. I believe this is rarely the case. It's far more important to understand the essential. The key to being a good leader is not to know everything better than everyone, but to understand how to help everyone contribute their best, then get out of the way.
> You seem to be under the impression that to be an authority one must have comprehensive and detailed knowledge, particularly in areas you care about.
Detailed and comprehensive knowledge is exactly what I expect from an authority on a subject. If they don't have it, then on what basis are they considered an authority?
It sounds to me - and I apologise if I've misunderstood - like you are arguing that a software architect doesn't need to understand the performance impact of their designs to be considered an authority on their subject? If so, then I respectfully disagree. It's possible to be a (bad) software architect without understanding that stuff, but I expect better from people who are supposed to be experts in the field.
> The key to being a good leader is not to know everything better than everyone, but to understand how to help everyone contribute their best, then get out of the way.
That's all very well but we're not talking about being a leader, we're talking about being an expert.
It's about the subject area. Fowler is an expert on OO architecture, not low level optimization. I think you're holding him to the wrong standard, and I think it's rather absurd to insist that anyone has a duty to be what you think they should be professionally.
The way I see it, they're linked. The memory hierarchy has a direct impact on a number of architectural concerns: data organisation, choice of components, communication patterns between components, etc. It can make the difference between a system that meets its functional requirements and one that doesn't. These are all things an architect is supposed to care about, so to me it seems reasonable to expect an expert architect to be aware of the factors influencing them. I get the feeling we're not going to agree about this though.
