Lots of programmers that I've met always says that "He is not a UI guy." The fact is that development nowadays, whether web, Windows, Linux, OSX, or any other type of development now comprises software with a good-looking UI. Why do so many developers seem to not like UI work?
I'm not a UI person either. Well, I do UI on my own projects, but at work I have nothing to do with it -- my work is in the guts of the app, not on the front end.
Beyond that, I think it's more boredom than hate. Designing the UI is the hard and challenging part. Implementation is mostly grunt work. There's very little challenge or innovation in how one can implement a user interface, and there's only so many times one can put a checkbox on the screen before going slightly mental. And that's not even touching on spending hours aligning pixels "just so".
Making a good UI involves a lot of different skills than writing some backend code.
Back-end requirements can usually be specified like a black box, x goes in and it's expected that y should come out. Making it work involves implementing the logic and you can programatically test whether it works or it doesn't.
To make a good UI, you need to consider usability, visual design, layout and things like colour schemes. Having some artistic creativity is a bonus here, and many programmers don't feel that they have this. To a logical brain the solution to a UI problem may seem subjective as there is no one correct answer or no easy way to validate that it is done 'correctly'.
I think a lot of programmers that don't have much UI experience or haven't done much research into it don't realise that there are rules and science behind both good UI design from both a usability perspective and a design one (e.g. colour theory).
Of course, some programmers don't have a problem with this aspect but hate it because many UIs are just boring to code. They may consist of a lot of repetitive work like pages of forms for admin pages where they just need to be functional and there is no design challenge.
People just have different interests. Some programmers are more interested in data stuctures and algorithms, some in architecture, some in usability and UI design- or any combination of those and other niches. They each require different skills and different ways of thinking about a problem. If you like the low-level nuts and bolts of programming, maybe you don't care as much about how the user thinks, or vice versa.
Personally, I fall into the latter camp- I'd much rather design a UI than a complex algorithm. It's just the kind of thing that I find interesting.
Whether a given UI design is good or bad is fairly subjective, which I think programmers in general find unappealing. A few decades of effort to quantify and qualify good UI techniques has helped to create some broad rules one can apply, but more often than not to really determine whether a UI is any good requires a lot of A/B testing and other user-observation techniques.
While there is certainly subjectivity in programming, commonly you can point to some form of objective reasons as to why one choice is better than another: speed of execution, memory requirements, flexibility to meet likely future needs, practices that have demonstrably proven more effective in the past, etc. Defending a given UI choice -- and therefor even making the choice itself -- commonly degrades to "I like it," which is a whole different kind of argument to support.
I personally do not enjoy UI development because I am not good at it. There is HUGE element of user psychology that I am just not good at understanding. I think my biggest issue is that I can't put put myself in the user's shoes. I do not know how to make intuitive layouts largely because I do not know what is intuitive to the user, nor do I know how to make things look pretty.
I don't necessarily think some programmer hate designing UI's as much as they hate doing things that they are not good at. It just happens that there are a lot of developers that are not good at UI development.
The problem with UI design is everybody has an opinion...And there is no right or wrong answer. Developers on the other hand love black & white and logic. In any size company everyone will agree that
1+1=2, but ask which font makes it easiest to read
(Comic Sans Obviously)...get ready for the flood. Ten thousand different answers and everyone is right, because everyone is different.
As a developer who actually enjoys working on UI (specifically, I've done my fair share of web design), I appreciate when someone who doesn't have the skill set stays out of it.
Developing requires the ability to hold a lot of data in your mind, and deal with a lot at once. UI design requires the ability to boil it down as minimally as possible, without sacrificing its integrity. I love the challenge of that; and I cringe when I see someone create a UI that's an unmanageable wall-o-data on screen. (I'm also a total geek when it comes to layout, color theory, etc.)
On the other hand, I hate low-level stuff. I will never touch code for drivers, kernels, or anything else like that :shudder: I'll leave that to the "non-UI guys", and I'm happy someone else enjoys doing it, or it would never get done.
I think it depends of most programmers use left part of their brain.
A good source for further reading of this subject.
UI development gets complex because you get too much input from the wrong people. They're all graphical design experts. They're no where to be found when you want to know the formula for something.
They don't know what they want but know it when they see it, have no taste, and those with the decision power won't use the application anyway but are certain it should be green. You follow guidelines for good UI like limiting the amount of fields on a form and you get a request to add 50 more fields because they 'need' all of them and having them on separate tabs is too much effort. You know, the same as Excel. Peasants!
You can't make this up. I sat in a meeting where the top two people in the accounting department (approx. 500K/year salary) for a large law firm spent half an hour arguing over a label on a billing website page used by the lawyers. This was suppose to make it easy for the lawyers to understand. Why not just ask the lawyers? Too easy. So the IT department gets to field 50 phone calls from lawyers wanting to know WTF "Residual Net Billing Amount" is and why is it on their time entry form.
Some people like broccoli, some don't. We might have to eat it, but we don't have to like it and we are not going to enjoy it when we do eat it. Not only that, we are going to avoid having to eat it as much as we possibly can.
There are A LOT of other things to code than just the UI. Web Services, Windows Services, embedded (not much of a UI on a microwave), just to name a few examples.
There are certain things in UI development that are difficult to get right.
Layout is one of them. I've been building UIs for over 15 years and have not yet still a decent solution to layout management.
Another is event routing - even with MVP architectures and stuff mandated by frameworks, I would argue that most complex UIs have event routing problems - which might be discovered if any of the testing frameworks could address them well.
I know that for me I used to hate UI dev because I found it very tedious and slow, especially writing layout code to position things in a form or winow. Now with UI designer tools such as the Forms Designer in Visual Studio, I almost enjoy it. Other reasons for hating it I've heard from others included "it's stupid", "it always changes too much", "it's not challenging enough", "it's tedious/boring".
I like working on the UI. That wasn't always true for me, but my enjoyment of UI work has increased as I've gotten better at it over the last few years. I do know some developers should not be allowed near a stylesheet, or a color palette. It's definitely a different skillset, and not everyone has it.
I don't as much hate UI work as I hate some UI frameworks. E.g. I've been programming .NET for >10years. The frameworks for creating web applications are great (ASP.NET WebForms and ASP.NET MVC). But the frameworks for writing desktop applications, well, I'm not fond of them (WinForms and WPF).
So in this respect, writing GUI applications is more an aspect of using frameworks I don't like.
There is another aspect. I often work with "enterprise"-style applications, i.e. applications where a desktop application needs to receive data from a server. In this case, there are so many layers of conversion of data from one format to another that it gets really really boring.
E.g. the application receives information through a series of DTO objects. The application then creates it's own model representation of the data (not reusing the same domain classes that were created on the server). The model classes are consumed by a view model (in a WPF MVVM pattern), that exposes the properties on the model.
That is a lot of times that the same data is represented by different classes. And that gets boring. But this is a problem specific to this type of desktop application.
There are also interesting challenges in this type of application, such as how do we get changes from one client to update immediately on another client.
I'm not a huge fan of UI development for these reasons:
As a developer, you have less freedom to create: The customer can see and have opinions about every little facet of the UI, which you have to react to. You'll get requests like: change the color of this; move that button there; never mind, move it back. The back-end code is rarely as visible.
UI is messier, while the back end is more "platonic." While I've seen ugly messes of back-end code, I think it's more common for it to be clean (from a code perspective) than UI code. A UI can be really clean looking and well designed for the user, but since I'm a developer and spend more time in the code than using it, I take a greater liking to clean code.
I feel that UI is more of a "plumbing" than the back-end, i.e. there's less opportunity for clever algorithms and really pushing your brain to the limit.
I do both UI (desktop, not web) and internal guts.
The amount I like or don't like either one depends on how much I can get done using something like a domain-specific-language (DSL).
In the UI domain, what I am presenting to the users, and the complexity of the information I am getting from them, is such that I would go crazy if I had to use typical tools, like forms designers, lots of event handlers, MVC, all that "state of the art" stuff. Thankfully, decades ago I discovered what I think is a better way, which is to make a DSL for it, and work in that. Currently I call it Dynamic Dialogs, and it's based on a control structure I call Differential Execution. The good news is, for a given functionality, the source code is roughly an order of magnitude less, allowing me to put a lot more functionality into the UI. The bad news is, as much as I've tried to teach it, I haven't had much luck transferring the technology.
In the non-UI domain, I took a lesson from a number of products that started out as DSLs usable from the command-line, on which a UI was later grafted. That gives the expert user something where they can bypass the UI, while giving the casual user something they can use casually. (Examples: R, SPlus, Matlab, SAS, WinBugs.) So our product has a command-line language for experts. I love developing such things, with a parser, code generator, precompiler, and run-time modeling engine. The effort spent on that is at least a power of 10 less than the effort spent on the UI.
One reason the UI effort is so much is there's still a lot of "glue" that can't be done with a DSL - managing data grids, all kinds of ways of sorting data, all the stuff that falls in the yawning "crack" between pure UI and underlying language.
So your question was "Why do some programmers hate the UI part of development?". I only hate it because of that "glue" for which I don't have a DSL.
Beyond what's already stated (it's tedious, boring, frustrating work to code it and the design is usually done up front by someone who has no clue as to what problems his ideas cause for those trying to implement them), an important factor is that you're having to work with people whose ideas about what you should be making change constantly, far more so than they do for the backend. As a result, you're shooting against a moving spec even more, and these people tend to be nitpickers too. I've literally have user interfaces fail tests because a components was 1 pixel off the location the person testing it thought it should have been. Did it work? Yes. Did it look good? Yes. But he started counting pixels and something was a single pixel out of line with the rest, so he sent it back for rework.
A few more points:
1) UI Design can be harder to test, sure you can check if that button does what it should, but testing if it is easy to use that is harder. How about testing if it will be usable with someone with a disability?
2) Many programmers are not trained on it, and don't know much about it.
Having worked on both sides of the coin i.e. UI design and the backend code, I found that both sides of the coin are basically the same thing.
Requirements that differ from what you do day to day do not come all the time and now in the era where all services revolve around CRUD then it becomes boring.
Anyway, coding the frontend allows better interaction and crazy dynamisms that basically screw an inexperienced hand in frontend design. I personally learnt the hard way in frontend and can comfortably say that designing frontend is far much more interesting and challenging.