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, Revealed
• Don’t make the Demo look Done
• Napkin Look & Feel for Swing
• Why xkcd-style graphs are important

It depends: You need a tight feedback loop around your most important piece of functionality

If the core of what you do, the risky and scary part, is some internal engine, then get the core part working in say the console or through unit testing. For example, a protocol parser doesn’t need a UI to know whether its operating correctly.

If your cool thing involves any interactivity — interactivity you need to be constantly troubleshooting, throwing away, and rediscovering — then a UI-first approach is crucial. For example, I want to build an app to let people interact with a data visualization. The most important thing I need to figure out is if the visualization is meaningful, so I’ll likely throw away a half-dozen approaches before settling on one. I’ll do this all before writing a single unit test.

There’s a fuzzy gray area in between where you get to decide the best combination on how to best interact and validate your code (automated tests? UI for experimentation?). I’ve personally done both extremes and everything in between, and deciding the right place to be on that spectrum is one of the hardest things I have to decide and is 100% dependent on the type of thing I’m building.

In an Agile environment, you might hear discussions of “walking skeletons” or “thin vertical slices”. The idea being that since working software is what is important to the user, you build out the software in a working fashion piece by piece.

In the example application you mentioned, you would start with the window and maybe one tab, and make it all work front-to-back in some fashion. Then over time, you would add functionality and therefore tabs on a case-by-case basis, making each feature work as you build it. This is part of what frequent customer demonstrations give you: a chance to show something new working and get feedback on it instantly.

In short, yes, UI work is absolutely part and parcel of a unit of functional work, if you have a UI.

Start with something small that works, and iterate its functionality up to deliver a full piece of software.

I would recommend making a mixture of both functionality and UI (and getting feedback or testing experience ASAP).

BTW, isn’t it the way that most large GUI software is developed? Look for example into the Firefox browser: from one version to the next both functionality and user interface have evolved.

In large (PHP web-based) applications that I work on, I try to get the classes and methods in place first, which return dummy values. This is to establish a pseudo-contract that the other devs can use to implement the UI for.

A secondary advantage to this method is that we can hone the contract / interface as the UI requirements change (and they always change), even before all the code is written and delivered.

What I tend to do is to start with a crappy UI: something that just dumps the variable data on the screen. No fonts, no alignment, nothing actually graphical for a long while. Just “Welcome user x” and buttons called “load pic” etc. What’s good about this is you will find out if something in the backend is broken.

As the development proceeds, you might find more things need to go on, or fewer. But at some stage, you will decide the backend is near completion. Now you have a UI that contains all the attachments needed, and you can spend a lot of time doing all the graphical stuff.

Beware though, it’s not foolproof. You need a bit of foresight to see certain issues arising. For instance, you may need to research UI components to display the data in a sensible way.

If you use a good milestone and issue tracking system, you can avoid some of these problem because at a glance, management can see how productive you’re being. They’ll be able to see that you’re 80% finished the backend and that the UI is the next milestone; they’ll be able to see that you have a set of UI and backend tasks to finish for a specific feature milestone. But it all starts with the project’s requirements, and Doug T’s answer raises some good points about that aspect of designing a system.

Think in your users/client point of view. A software system is a collection of features that gives this users/clients some value. Of course each one of this features have and UI, a backend and some other things.

Build your system always feature by feature, and try divide in very small features. This way you are always near to have something more to deliver to your customers, remember that software development its not about build the version 1.0 its about going to the version 1.0.1 to the 1.0.2 and so on…

It depends. How well defined are your requirements? How much of the system is UI facing?

From my experience most customers do not know what they want until they see something in front of them. So I normally provide some wire-frames of key UI aspects or deliver the majority of the UI (non working). This allows for the customer to change their mind on features/functions without too much impact as the database design and code structure is still only in design phase – it is easy to amend the design.
It is orders of magnitudes easier/quicker to change design earlier in the project then later.

Agile states you should also work on the most difficult items and the most important items first. Fail fast. So once the customer has seen the UI I focus on building small components which are fully functional talking the most important and hardest to implement first so you know as soon as possible if your going to run into any hurdles.

Then you have your sprints and have constant communication with the customer developing both the UI and functional aspects at the sometime.