I like to do a wireframe before I start coding and work from there. But when should I start worrying about the visual design? When should I consider the colours, the font, whether corners should be round or sharp, icon design, etc?
Is that the last thing to do before launch? Or is there any reason to work on it while you're still in the coding phase, or testing and debugging phase?
I'd like to say that as a programmer you shouldn't be creating the visual design at all, instead handing that off to UI and graphic designers, but unfortunately I know all too well that most companies aren't willing to invest any money in that unless it's going to directly generate revenue.
So the next best thing is to wait as long as possible before getting into that. You can hash out most of what the UI is going to do with tools like Balsamiq or the free Pencil, and if you're using a good presentation architecture (MVC, MVP, MVVM, etc.) then you should have no trouble at all testing the UI functions without an actual UI.
The more complete your GUI design is, the more everybody else who sees it is going to think that you're "almost done". You don't want this. Back when I did mostly Winforms development, I tended to start with the UI first, but I've since learned my lesson, and now it's always the last thing I do, after the controller or view-model unit tests.
The other issue is that it's simply a distraction and requires you to approach the problem from a completely different perspective. If you spend too much time working on the GUI when the library/model/business/domain code's not done, you're going to hurt your own productivity from the constant context-switching. People aren't very good at multitasking; don't do it if you can avoid it.
If you're working solo and doing everything yourself, I'm actually going to suggest sort of the opposite of the popular route (if only to complement Aaronaught's fine answer).
And I actually recommend doing like 75% or more of the GUI work for your application sort of upfront, earlier (but post architectural conception), kind of stub things in there, pseudo-RAD style. You don't have to get to the meticulous details like fonts and stuff, and can keep the icons using stock graphics or just labels like "X". It's more about a sense of UI "completeness" than beauty. Maybe I would say, "very incomplete" from an aesthetic aspect, but mostly complete in terms of having all the major UI elements there.
SE vs. Psychology
The main reason is not software engineering discipline. This is actually quite a violation of it. It makes the most sense from an SE standpoint to prioritize the stable designs (high efferent couplings, low afferent couplings, when UIs tend to be among the most unstable designs).
The SE formula to prioritize stable designs is ideal for redoing the least amount of work as you progress, since UI frontends depend on backend, but not the other way around. If we had a fully-established frontend first, we might have to keep changing its code as the backend changes while we're finding some unanticipated needs for design changes here and there.
But there's just a morale/motivation/human psychology aspect to it. If you're like me, the hardest thing about working solo and not having the pressure of the company is just staying self-motivated. I have my little slumps.
It's hard to stay motivated if, after 2 months of coding, your application looks like a raw skeleton from the UI level and none of your kind of internal test users understand what they're even looking at with only screenshots of console outputs and very barebones UI.
If you're like me, my notion of "software progress" is unfortunately not too unlike the naive user, judging the progress of the application by how finished the UI looks. It shouldn't be, as I ideally just have the discipline to measure my progress without looking for that kind of casing, "shell" that decorates the unfinished backend. But I don't do this perfectly, I subconsciously judge things by that front-end as many users do, and I get depressed when that perception is one of slow progress. When it looks promising, it keeps me motivated.
So I actually feel like it's easier from a self-motivation standpoint to kind of get that GUI established upfront (but not little details, just the overall idea).
The other reason I like this is that, counter-intutively, I tend to do a lot more juggling of the UI and backend when I'm trying to do it the more formal SE way. Even though I've tried this hardcore SE prioritization strategy where I tried to do the minimal work for the UI, I found myself constantly doing a little bit of it here and there with the UI inching in progress a little bit each day, and the time added up. By getting the bulk of it out of the way upfront, you can go in long bursts filling in your application's functionality and start measuring progress by what things stubbed into the UI are left to implement. There might be some backend changes that require you to change the front-end you established upfront -- there's always interruptions like that, but overall I found myself juggling the UI code less (YMMV).
The UI starts to become like an implicit "todo" list in this case (though not an excuse to avoid having an external one as well).
The only problem with this is that the UI design tends to drive the backend design, which is usually not what you want. If you find that your backend work is driving the UI design, you need better decoupling (i.e. View Models).
From Robert, I very much agree. It's kind of a blur to me always when working on my own. I apply a strict adherence of the MVC, but a trouble I always found is that the model can become very complete while the view is so rough, or I'm trying to evolve them together and juggling a lot.
It may also be a bit unique to my situation. I work in areas like games and audio and kind of "visual applications" where my UIs are all proprietary (somewhat of a standard aesthetic in these areas) so I'm rolling all my widgets, async UI thread, event handlers, alpha blitting pixels, rasterizing antialised shapes, font rendering engine, bevel and emboss filters on small graphics, property system with reflection (for MVC), async signals and slots, retina display support etc. all by hand while simultaneously juggling low-level audio processing, image compositing, video filtering, raytracing, localization, mesh algorithms, particle systems, undo system, non-destructive pipeline, scripting engine, SDK, etc. So the "view" part is actually considerably more work than usual in my case. My apps look kind of unusual like this:
In the early stages (first few months) of this project I got really depressed, since I was looking at stuff like this:
... with only one button in that entire sidebar for the paint tab, e.g., and there were times I was just tempted to quit working on the project because the UI looked so incomplete even though a lot of the backend was mature. I started reversing that strategy and seeking a more complete UI in the middle of the project (just buttons and stuff stubbed in to kind of capture the final product's overall UI-level functions) and that really helped my motivation.