Often, the best approach is a blend of the two, I find.
Identify the aspects of the problem that you don't understand fully, and which aspects are likely to change. There's usually some part of the problem that you do understand.
Then spend a day thinking up an elegant framework that allows you to experiment without making a mess. Small classes that can be swapped out or added and removed as needed. Modules that can be customized and moved around. A strategy pattern that lets you tweak your algorithms as you get more data. Whatever makes sense for your application.
"Hacker style" is no excuse for sloppiness; nor is "Djikstra style" any excuse for slowness.
I second for that. Actually I think the OP's description of two styles is two extreme cases of one spectrum. Plus, the OP doesn't distinguish difference in the size of the problem domain.
Standing out academic papers looks perfect and it seems as if the authors come up with the final version immediately, but in reality, many problems dealt in academic papers are attacked progressively. For bigger problems, you'll find series of papers beginning from special case solutions to more general ones. Wiles gave a proof of only special cases of Taniyama-Shimura since that's enough to prove Fermat's last theorem (so I heard; I can't understand the actual paper).
On the other hand, if you're writing critical part of nonstop software and trying to fix a bug related to multithreads, you want to iterate every possible timing combinations to make sure things won't be possibly broken. It's much like the process of writing math proof.
And there's a problem domain. Djikstra style works well when applied to the problem whose domain is well understood. That's why it requires much thinking before actually writing solutions; you have to understand the problem clearly enough. For many software, the envionment in which it runs is more vaguely defined; anything that interacts with human has to incorporate this big unknown, unpredictable element which is called human. The software that supports business must adapt to the business process, in which many details are left to decisions of skilled human without any explicit rules. Software for such problems can't have the well defined domain before start writing in Djikstra style.
Identify the aspects of the problem that you don't understand fully, and which aspects are likely to change. There's usually some part of the problem that you do understand.
Then spend a day thinking up an elegant framework that allows you to experiment without making a mess. Small classes that can be swapped out or added and removed as needed. Modules that can be customized and moved around. A strategy pattern that lets you tweak your algorithms as you get more data. Whatever makes sense for your application.
"Hacker style" is no excuse for sloppiness; nor is "Djikstra style" any excuse for slowness.