[evouga]

This seems to be the case with a lot of "methodologies" like TDD, Agile, XP, etc. as well as "XXX considered harmful"-style proscriptions.

A simple idea ("hey, I was facing a tricky problem and this new way of approaching it worked for me. Maybe it will help you too?") mutates into a blanket law ("this is the only way to solve all the problems") and then pointy-haired folks notice the trend and enshrine it into corporate policy.

But Fred Brooks was right: there are no silver bullets. Do what works best for you/your team.

[bitwize]

The 2000s design-patterns-mania is another case. Design patterns should be thought of less as things you have to memorize and apply in a textbook fashion, and more like tropes: things you'll see over and over in code, and once you know their names you can start talking about them and their interactions in meaningful ways. Just as writers like tropes because they make the job of writing easier, overuse of them is a sign of laziness; and so it is with design patterns.

[cpill]

yeah, I find software engineers like to find absolute answers to fuzzy problems. I guess it's the nature of the job