Kevin has been working with Java for 10 years, in defence research through dot com to investment banking. Currently he works at 
Give the user what they want...
...and a few things they need.
I used to subscribe to the school of thought that you should write, or at least design, your system solidly and then build your user interface(s) on top of this sound foundation. After all, it's got to work before you can use it, right?
I'm not so sure anymore, though this is mitigated somewhat by an iterative process. I've more recently shifted towards the notion that each function must be usable before it can be used. After all, its main purpose in life is to be used, not to be strategic/beautiful/standard/optimal, right?
People, particularly developers, tend to dismiss the user interface as being the "front-end" to the application, simply adapting between business function and user. This is only really true once it is complete; during development the UI is defining and refining the business functions - it is part of the development process. When implementing user interface first it is often the architectural assumptions that get changed since they don't fully support the desired functionality. This is a good thing - it is refining the architecture and making it fit for purpose, the purpose being to serve the user.
Of course you're stuck trying to balance functional and non-functional requirements - just remember that the users carry a lot more weight than you might first think! If the end users don't want to use your application you'll struggle to get it adopted whereas if the end users do want to use it they'll give the project real inertia, biting your arm off for new features.
Also, whilst it may seem a bit Machiavellian, it's quite easy (and sometimes fun) to ride an unrelated architectural improvement in on the back of some new user functionality. The development effort's got impetus so why not make the most of it and champion your own requirements?
The overall quality of your system should improve with the addition of functionality.
The development of new functionality requires the refactoring of related code, thereby improving it. This development also facilitates the refactoring of unrelated code - an opportunity worth taking!
