1

Joel Spolsky once wrote that 90% of a software project is not its visual parts:

If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is 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.

Since many applications have the UI designed first, what are some effective ways that the development team can show progress when their work is essentially invisible?

gnat
  • 21,442
  • 29
  • 112
  • 288
Bryce
  • 1,999
  • 2
  • 12
  • 7
  • [Sharing your research helps everyone](http://meta.programmers.stackexchange.com/questions/6559/why-is-research-important). Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] – gnat Jun 03 '15 at 09:43
  • 2
    Closely related: [Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?](http://programmers.stackexchange.com/q/251349/40980) –  Jun 03 '15 at 14:20

2 Answers2

5

If there is no visualization for what you do, create one.

It doesn't matter if it's a time-series graph, a burndown chart, or any other quick-and-dirty visual. (In fact, quick and dirty is what you want, since you want to spend your time on programming and not on reporting.) Once you've demonstrated a series of slowly expanding deliverable measure to the people above, they will begin to understand that there is more to programming than mock-ups.

(Slowly begin to understand, to be sure, since they're people above and not engineers. But I've given up trying to convey to non-technical people exactly what the point of my work is, since the battle is not worth the effort.)

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
3

One trick is to keep a separate CSS for early demos.

Basic fonts and no fancy graphics and drab color scheme, all reinforce the idea that this is something under development.

The other trick (not really a trick -- you should be doing this anyway!) is agonize over the fine details of the background use cases ( most likely the actual business rules ) with your users so they get a feel for the complexity of the implementation (and hopefully improve your understanding of what they really want).

James Anderson
  • 18,049
  • 1
  • 42
  • 72