47

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.

RobotHumans
  • 906
  • 8
  • 11

9 Answers9

86

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:

How done it is to what it looks like

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):

  • 7
    Sounds like you're proposing some kind of [agile methodology](http://en.wikipedia.org/wiki/Agile_software_development)... :) – Alexander Jul 27 '14 at 18:32
  • 7
    @Alexander Agile helps in this case, but isn't essential. Waterfall can have (deliverable) milestones and customers can be very disappointed at seeing the "it looks done, why are there 3 more mile stones that take just as long?" FWIW, I've had instances where the business user thought it was done because of the screen shot + ms paint in the *tech design* (waterfall shop) looked good. –  Jul 27 '14 at 18:35
  • Indeed, dealing with "not so technically inclined" business people, there can be some misconceptions. [youtu.be/BKorP55Aqvg](http://youtu.be/BKorP55Aqvg) – Alexander Jul 27 '14 at 19:14
  • 1
    @Alexander - you made me smile quite a bit with that one. – RobotHumans Jul 27 '14 at 19:38
  • 3
    In case you did not see an expert answer to that video, here it is: http://youtu.be/B7MIJP90biM – ragol Jul 27 '14 at 22:09
  • 1
    +1 to @Alexander comment. But an Agile _approach_, at least, to developing functional bits. And a "bit" does not have to mean a complete, fully functional, screen. – radarbob Jul 27 '14 at 22:41
  • @radarbob Excellent point. I think *"Deliver incremental builds and make sure you're making what the client wants"* describes an agile approach, as work is typically done "bit" by "bit" (i.e. feature by feature, issue by issue, etc...) without presupposing traditionally agile things like sprints, CI, TDD, etc... – Alexander Jul 28 '14 at 00:19
  • @Alexander I've expended/reworded the bit on builds to make it a bit more clear what i was trying to get at. Do you have any other suggestions? –  Jul 28 '14 at 00:30
  • UI couples to and informs feature development. Therefore UI is highest risk *and* changes the requirements as it develops. This is true for technical risk in the backend ("whoops there's no algorithm to do this fast enough for what the user requires") but in practice far far less. – djechlin Jul 28 '14 at 01:16
  • @MichaelT - looks good! Also, on a bit of a tangent, I've found it helpful to use analogies when setting expectations and explaining complex things to business people. Such as, mockups and requirements are to programming software, what concept drawings and blueprints are to constructing a building. Nobody (in their right mind :) expects a building to be nearly ready to open when there's only a blueprint in front of them! – Alexander Jul 28 '14 at 05:31
  • 3
    I've been designing UI's for the bulk of my programming career and NOT ONCE have I had a client assume that a prototype UI meant that the software was 'almost done'. It sounds to me like the presenters of wireframe UI's are not doing a good job explaining the wireframes up front if the clients are somehow confused into thinking that the project is almost done. – Graham Jul 28 '14 at 13:24
  • I guess you were trying to link [to this](http://www.joelonsoftware.com/articles/fog0000000356.html)? That link in your answer points to a tag on sqa.SE! – Two-Bit Alchemist Jul 28 '14 at 16:02
  • 2
    +1 for Napkin L&F. That will surely be in my future. :) – Kathy Jul 28 '14 at 18:07
  • @Two-BitAlchemist thank you - I must have had the wrong thing in my clipboard when I worked added that and didn't realize what I was pasting (multitasking and context switches of the brain isn't always thread safe). –  Jul 28 '14 at 22:30
  • This answer is still wr*ng. You seriously think there's a bigger risk of a perfect UI that looks too good, over a UI that invites a zillion feature requests small and large that reveal the original spec was all wr*ng? – djechlin Jul 28 '14 at 22:38
  • 1
    @djechlin you are welcome to that. Many times I have dealt with people who think that when it looks done, its 90% done and everything else should be done Real Soon Now (and any estimates that programmers give to the contrary are them just padding numbers and slacking off). If you have been able to avoid these business users and clients, you have been lucky and I hope that your luck continues. There are indeed issues with iterations of feature requests based on the UI that should be addressed too, but scope and feature changes on that first 'it looks done' can spiral with it never getting done. –  Jul 28 '14 at 22:49
  • 1
    @Alexander in my expansion of "Don't make the Demo look Done" there are some anecdotes in there linking to [this talk](http://scobleizer.com/2006/12/04/microsoft-targets-adobe-why/) about how the flash presentation given by Microsoft for Vista lead to developers thinking things were more final than they were, and even the executives thought they were seeing real things. Its about setting the expectations and some people have difficulty understanding the difference between the blue print and the final product - if the facade looks done, the rest is done too... right? (or so the expectation is) –  Jul 29 '14 at 01:35
  • 1
    @Kathy from the math world, you may be interested in http://www.chrisstucchio.com/blog/2014/why_xkcd_style_graphs_are_important.html which leads to graphs with less exactitude (and thus less importance on the raw numbers and more about the shape / context). –  Jul 29 '14 at 01:38
  • 1
    @Graham: It depends on who you're working for and what their management is like. It's more typical of non-technical management, and especially non-technical management that loves deadlines and is accustomed to seeing half-finished products ship. – Aaronaught Jul 29 '14 at 02:27
  • 1
    Comment thread's starting to get a tad long. Consider taking this discussion to [chat]. –  Jul 29 '14 at 03:31
  • 1
    I would tend to disagree with this 'Don't make the Demo look Done' it seems like this approach is more about managing customer expectations then what is the most efficient use of resources. Yes it is important to manage expectations but this still be done in other ways – Daveo Jul 29 '14 at 04:24
  • @MichaelT You are my hero for that link. Thank you! :) – Kathy Jul 29 '14 at 14:23
  • Yes this is how good dev is anyway really (in most cases). Often design or coding front or back separately leads to revealing design flaws or missed requirements when you start to later code the other side. E.g. do a page at a time (back end/controller/services etc, front end to show it). Then you can show case login/reg/some page is done which shows progress for a specific page. They see progress, you are 99% done with that page. – James Feb 09 '20 at 00:48
27

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.

Doug T.
  • 11,642
  • 5
  • 43
  • 69
  • 2
    I.e. identify and address the riskiest and most critical components up front so as to mitigate the chance of overruns and/or failure. Whether those components are the UI, business logic, etc..., or most likely, some combination of all the various components. – Alexander Jul 27 '14 at 19:21
  • 1
    It really sounds like you're talking about prototyping to me, because if you're still throwing designs away then that's what you should be iterating on - not actual code. – Aaronaught Jul 29 '14 at 02:25
8

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.

Kate Bertelsen
  • 181
  • 3
  • +1 Always having a shippable piece of something is essential. – JensG Jul 27 '14 at 20:37
  • @Jens:"Always having a shippable piece of something is essential" is a canard. At best that saying only applies to a minority of software applications. In the real world, applications which only do part of the job needed aren't useful in the slightest. – Dunk Jul 28 '14 at 14:25
  • That's your experiences. I have different ones. Large, real-world projects with plenty of milestones and real customers included. – JensG Jul 28 '14 at 16:25
  • 1
    @Dunk: An application that doesn't do any part of the job is less useful than an application that does part of the job. I am not, however, talking about an application that is "done"; I am talking about the order one should build an application. My experience is congruent with JensG: always being able to cut a beta based on what you demoed that week and ship it to the clients immediately makes clients much happier. – Kate Bertelsen Jul 28 '14 at 21:09
  • This is the only answer I can identify with. The others don't even seem to be considering the possibility that good product development doesn't break down cleanly into "UI" and "back-end". It's a question that only a newbie programmer or project manager would ever ask, and not one that an experienced programmer or PM should deign to answer at face value. The very idea of asking which should be "done first" stinks of waterfall. – Aaronaught Jul 29 '14 at 02:23
  • Essential and happier are 2 very different things. – Dunk Jul 31 '14 at 19:59
  • @Aaron:It is very seldom that I can't develop UI and application entirely separate from each other. However, most products I work on require multiple means of control so I am forced in that direction to begin with. Also, I don't have a clue why you would think that good product development doesn't break down cleanly between UI and "back-end". If the UI and application don't have clean separation then there's likely something wrong with your design. – Dunk Jul 31 '14 at 20:17
  • @Dunk: Architecturally, yes, presentation is generally encapsulated and kept separate from other concerns. But I said *product development*, not *coding*. Product development is a process that involves multiple skill sets, business departments and stakeholders, and the UI is the part that (almost) all of them will want to get involved with. Accordingly, if it's done in a business silo, then you'll usually end up with an unusable product, and if it's done in a technical silo, you'll usually end up with a design that at best requires terrible hacks, or at worst can't be implemented at all. – Aaronaught Jul 31 '14 at 20:44
  • @Dunk: I'm not sure what you're arguing. That we shouldn't use iterative development processes because software that isn't done is useless? – Kate Bertelsen Aug 01 '14 at 21:14
  • @Keith:I never said anything about not using iterative development. I was nit-picking on the word "essential" and pointing out that most products aren't of any value to a customer until they have the system's requirements pretty much ALL working. Without being able to see how the pieces fit together (ie. the UI) most people can't give meaningful feedback. A working "canned" prototype UI where functionality is added as it is developed does far more in getting constructive feedback than piece-mealing UI and functionality as it is developed. The customer can't see the big picture piece-mealing. – Dunk Aug 04 '14 at 19:45
3

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.

Basile Starynkevitch
  • 32,434
  • 6
  • 84
  • 125
2

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.

dotancohen
  • 1,001
  • 1
  • 8
  • 19
  • This is something I'm trying to sort of do. Since my particular project is implemented as a massive UI shell and every datapoint harvester is a plug-in, each plug-in is responsible for managing its own UI components. This way there is no "contract" required for a given person/group of people. The assumption is that the same group of people will be working on a given plug-in start to finish. It's part of the reason I'm designing it the way I am. Alternately, for other projects this is an excellent piece of advice. So upvote from me since it will be useful to others. – RobotHumans Jul 27 '14 at 17:56
2

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.

Carlos
  • 874
  • 7
  • 13
  • And where does the customer come into play in your methodology? Keep in mind that usually your customer only has a very general idea of what they want. It's up to you to figure out how to "draw out of them" exactly what they want so you can build it. Your methodology just built what you think the customer wants but that will seldom be what the customer actually wants. So you've just wasted a ton of time coding something the customer doesn't want. – Dunk Jul 28 '14 at 14:30
  • Ah, my "customers" are sitting right next to me, and I have a background in the field that gives me a pretty good idea of what is wanted. Basically we are always close to the end product, UI wise, and I can always get feedback. I hadn't considered the problem of having a long feedback loop. I guess having the domain knowledge is key. – Carlos Jul 28 '14 at 14:48
0

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.

Derek
  • 174
  • 5
0

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...

AlfredoCasado
  • 2,159
  • 11
  • 11
0

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.

Daveo
  • 900
  • 6
  • 12