Jeff Atwood asserts that it is important to get the public interfaces right before worrying about how the code looks. Somehow I got a feeling that quality of the code and its working were being posed against each other. They need not be. Or, that is what I believe is the benefit of following good programming and project management practices.
If code is the product, it has two different kinds of customers. One, of course, is the user of the application, where the code is invisible. It is the application which tells whether the code works or not. But in the long term, it also talks about how the code was written. As the application gets used more and more, problems change, there are requests and suggestions, and the code evolves. These changes are expensive, but good code can help in making these changes easier. It can help the application evolve better.
And that is where we meet second kind of the customer for your code. The maintainer or the developer who sticks with the code and makes changes to it. Software development is never a one-time activity, it is continuous and we need infrastructure to maintain that continuity smoothly.
I do not think the code can afford to ignore any of them. One pays for the software, and the other enables that. In certain phases of software development one might weigh more than the other, but they are not mutually exclusive. Working code is an apparent necessity, but good quality of the code might be realized over a long period of time. Any software development activity should invest in both.