Well, CORRECT design is everything. Except in most cases you can't tell whether your design is correct in the first place. Some things appear to be impossible to do in practice. You must try workarounds. If they happened to be key points of the project, suddenly your whole design crumbles. Some things don't work like you'd expect them to work. So you have to make in-place fixes, and without repeating a thorough analysis of the design you can't tell if they affect it or not. Some things you just can't know beforehand, you see them when you arrive there - too many unknown variables that can't be determined at the designing time. Until you see it working you don't know if it will work and whether all the time and effort you've sacrificed in planning and writing all the pretty code won't go waste.
The problem is that creating maintainable code is costly - in means of time, effort etc. From my experience, core functionality of any given program hardly ever accounts for more than 5% of the source code. The rest is all initializations, configuration, user interfaces, exception handling, sanity/safety checks, converting the I/O data to usable format, APIs for selected sub-tasks, customizablity, lots and lots of code that has no direct relation to work at hand, but comprises all the "good code". And this all is great, except if the basic 5% doesn't work, the rest is worthless. So my tactic is to first get the general idea, get the thing to work. Replace all the non-essential parts with stubs, provide friendliest possible environment to avoid need for exception handling, and just get some basic testcase through. If I know it will work, I may start designing the whole system, rewriting the whole code from scratch, in a maintainable and "right" way (check all your pointers if they aren't NULL, check those return values, don't assume they are "okay", save resources, perform safest optimisations etc). And if my new code doesnt't work, I still have the prototype to fall back to, to compare, and see what I'm doing wrong that breaks the code.
So, my priority is to write code that works, and only after that one that is maintainable. I just don't make the world suffer using my unmaintainable code. It never leaves my harddrives.