The crux of my argument is relying on methodologies to write good software or to guide a design is pointless.
Instead of trusting everything you read, you should question it an consider it in practice before you actually follow it.
Instead of trusting everything you read, you should question it an consider it in practice before you actually follow it.
> Instead of trusting everything you read, you should question it an consider it in practice before you actually follow it.
But once you've questioned and evaluated it, its still a methodology. If you just mean you shouldn't take published methodologies on faith but consider how they work in your particular environment, that's widely accepted truth. Its, among other things, a central idea of the Agile software movement, as well as central to Lean methods (not just in software, either) and, more generally, to all models based around a Plan-Do-Check-Act cycle and variants thereof.
Its hardly a controversial or new observation, though there are plenty of failures to put it into effect.
I already got that. It's already in the title of your post. You're just restating the title again.
But in the body of the text, you gave your reasoning and arguments attempting to explain why it was pointless. I'm pointing out that your reasoning (e.g. "different definitions") does not support your title. You need to construct a better set of arguments to convince people of your thesis.