For myself I agree, but I was never big into engineering approaches. Very suspicious of agile methods, too. The way I see it: for example in mathematics the first proof of a difficult theorem is often very long and complex. Over time more mathematicians might look at the proof and find ways to make it simpler. Eventually you might have a 5 line version of a proof that used to be 30 pages long.

I don't see how any agile method or engineering approach could help much in getting the 5 line version from the beginning. There always seems to be a kind of "crunch" step involved in solving the problem. Once the problem is solved, the solution can be cleaned up. But solving the problem at first you explore maybe hundreds of possible paths in your mind, and combine lots and lots of aspects. You are stuck in the jungle and try to find a path to the summit. Once you are on the summit, you can look down the mountain and see the easier routes you missed on your way up - because in the jungle you can't see very far, and you have to fight for every meter of progress.

I find the same applies to my own code - which is always crappy, anyway. But refactoring usually goes quite fast once the first working version has come into existence.

I'd expect having to focus on getting some agile method right would just distract me from solving the problem.