Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?  Assuming you're working on something large, is it generally accepted practice to get all the functional data harvesting blobs working before any UI, get all the UI working one piece at a time as you go, or something in the middle?  We all know to break work down in to manageable pieces, but the question is ultimately whether UI is included in manageable pieces I suppose.  For the case of the example, consider a GUI application with one root window, but over a dozen tabs in various docks to separate different data components.  Each individual tab has a relatively complex set of moving parts behind it from a functional units perspective.    The example application in this particular question is here with the accompanying blog and the original commercial product.
Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?
project management;user interface
There is a general conception amongst many business users and clients that when it looks complete, it is almost complete.  As you likely know, this is far from the truth.  One can have it looking nice, but with no backend and some users think that making it look nice is 80% of the work, not 20% (or the other 80%).Countless developers can tell horror stories of this - getting a mockup of the pages done in Microsoft Word using screen shots of some other tool, and the client saying so, you've almost got it done?You need to pace it so that all parts are done when its done.  Trying to do all the backend first and then all the front end will lead to the end user thinking you're not doing anything and asking why you are getting paid when there is nothing to show for it.  On the other hand, front end first and you'll find the end user making niggling changes and consuming all our time.The worst case with a 'one first and the the other' is when you get to the other part, you find that it doesn't fit the design at all.Thus, build both.  Show progress in the front end, make the back end work with what you are building.  In many cases its a good idea to deliver incremental builds and make sure you're making what the client wants (this gets into Agile).  Going too long with out 'visible advances' can hurt the client relationship (this is for both cases of 'everything looks done early' and 'nothing is done until the very end' - its hard for the client to see the framework being written or the unit tests or data sanitization as progress).Joel wrote about this in The Iceberg Secret, Revealed:Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think oh, gosh, how much harder could it be to make it actually work?The big risk here is that if you mock up the UI first, presumably so you can get some conversations going with the customer, then everybody's going to think you're almost done. And then when you spend the next year working under the covers, so to speak, nobody will really see what you're doing and they'll think it's nothing.This is again reiterated in the blog post Don't make the Demo look Done which has this helpful graph:Note here the two options generally reflect the 'get the ui done' (and then the expectation is that you'll be done soon) and 'get the backend done' (and then the customer is worried about you missing the deadline).How 'done' something looks should match how 'done' something is.Every software developer has experienced this many times in their career. But desktop publishing tools lead to the same headache for tech writers--if you show someone a rough draft that's perfectly fonted and formatted, they see it as more done than you'd like. We need a match between where we are and where others perceive we are.This article also brings up an important point about the type of feedback you get with different levels of doneness of the user interface.  If you have something that looks complete, you're more likely to get feedback about could you change the font than this layout doesn't work - there are too many tabs.For those who are fighting with this in the Java Swing world, there's a look and feel called Napkin which makes it so that the UI doesn't look complete (even if it is).The key here is to make it so that it doesn't look done.  Having the UI look complete is a signal to many business users that the application is complete (even if its just a few static pages without any logic behind it or something built in an interface builder).Further reading (and links from article):The Iceberg Secret, RevealedDon't make the Demo look DoneNapkin Look & Feel for SwingWhy xkcd-style graphs are important