I, too, disagree, but not strongly. Author used the adapter pattern in one of his examples. I think this pattern comes up more often when refactoring than when doing initial design. Not always (there are never any certainties), but usually. So, I think the warning should be more, be careful in what patterns you choose and it's ok, for now, to choose none.

What you're describing sounds more like a teamwork problem - you're likely either missing someone with the "big picture" who is reviewing code, or a collaborative code review process.

I would agree that lacking either of those things would cause the problem I described, but in this case we have both of those.

Most recently, I was the one joining a project after its incipient stage, so I was not the big picture guy, but the big picture guy chose not to establish any kind of patterns or standards so when others started joining the project--even with an understanding of how it should work--suddenly the app had a lot more functionality but it all performed terribly because of a lack of uniformity in design. Code review helps, but ultimately because there are no established patterns there is no justification for telling someone a task should be implemented differently, right? The only solution I can see is to establish that justification by trying to get the big picture guy on board with a massive refactor to establish some standards.