> 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.
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.
> 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.