> My main criticism here is about how the vast majority of developers react to all these things. It is not just because someone, somewhere wrote a book, recorded a video or gave a talk in a conference about something that it will make that thing right, in all contexts.
The vast majority of developers probably don't care much at all about development methodologies. The author notices the vocal minority and mistakes it for the majority.
To play the devil's advocate, what happens when that vocal minority happens to be in a leadership position at your company, like the director of engineering or CTO? It doesn't even have to be a programmer who is infatuated with a methodology in order to push it out onto other developers. Very rarely do we individual programmers choose to use the methodologies of which we are subjected.
That's fine, but the author explicitly stated that the article was written because "the vast majority of developers react to all these things." My point was that this statement seems to me to be untrue.
Providing a consistent interface to the development team adds value. Consistency within the team itself adds value as well. Picking something from the big list of methodologies and doing it consistently gives better results than doing whatever on wednesday afternoon. If nothing else, it lets teams identify procedures that don't work for them, so they can customize the methodology for their environment.
The vast majority of developers probably don't care much at all about development methodologies. The author notices the vocal minority and mistakes it for the majority.