Is the UI a valid indicator of internal quality?

Question

When looking at the myriad types of software written at our company, I instantly jump to conclusions of the quality of the entire product based on the UI. If I find misspellings, weird tab orders, fields not lined up, odd colors, I assume that the entire application is of poor quality.

I'm assuming that if the programmer doesn't care enough to make the outside look good, that they don't care enough at all. I am NOT assuming if the UI looks good that the application does what it should, although I am not immediately down on it -- it gets more leeway when it's being evaluated.

Is this a valid decision to make? For commercial software as well?

Answer 1

In my opinion it is a valid decision. And you are right when you say that good looking software is not necessarily good software internally.

But definitely, if the programmers don't care about the usability of the program, most likely they won't care about it's functionality.

Answer 2

I think it's a good indicator of the care that a developer has for their work - basically a sense of professional pride.

It's a given that most devs don't make fantastic UI designers, but there are a basic set of rules that should be followed when developing professional software and these apply as much to the UI as they do to the internals.

So, basically I agree with you.

Answer 3

If the UI is riddled with typos and inconsistencies, it is probably fair to say that the QA process and project management were a bit lacking. Doesn't really infer that the codebase is riddled with bugs.

In a commercial product, it most likely means that less people will buy it, so whilst sales are not really a quality metric, they're pretty important in the overall scheme of things.
People are more likely to buy things that look good, behave as they expect them to, and "Don't make them think".

Many programmers suck at UI design, and that's not their fault, it does not mean they suck at coding. They're just generally more interested in the internal beauty of what they make, otherwise, they'd be liberal arts majors instead.

Answer 4

It really depends. I know of software developers who are excellent at just about all aspects of design and implementation but have lousy UI skills. Many times the UI is an afterthought as a nod to the user. In the cases of scientific software or other software where the processing is central or key, it might not be a good idea to judge the quality of the rest of the code by the UI. However, overall - it might be a good indicator that the software company has not done its job well.

It all really depends on each case, but if the UI is not usable or a pain in the neck, then the underlying code is harder to use and not worth the time I suppose.

The opposite is also not true - flashy, beautiful UIs do not mean that the underlying code is good at all. Anyone can wrap a piece of junk with a nice UI.

Answer 5

IF the application was written by one developer its not an unfair assumption that a slovenly UI is indicative of the underlying code quality.

However if it was written by a team of 5 or 7 or 13 there will likely be a wide range of quality under the hood (it just might be the newbee was given the UI).

Also if the app is 5+ years into its lifecycle with maintenance being performed by FBN contractors or interns or whoever is handy you may find a lot of good code under the hood thats slowly rotting because of indifferent management and undisciplined developers who just throw a "patch" at it, compile it, check it back in and throw it over the wall to production.

A crappy UI can be indicative of a lot of things, none of them good, some worse than others.

Answer 6

I'd agree with the masses here. Poor UI mean that the product development team dropped the ball.. That said. I consider myself a good coder. Great at math, but dyslexic and attention deficit disorder.. Give me a set of earphones and some code and I'm on my way. Don't however expect me to mock up a great GUI. Line things up.. That I do.

Now ADD to that the fact that as the "programmer" even when I see things in the GUI that bug the crap out of me (as a person who uses it), I don't get to fix them.. Hell when I do fix them I get QA asking me for the design document and the approval from on high. After a while I stoped caring about the GUI..

I write solid code, that works. It's fast, clean and small.. it's where I get to have an impact. The GUI is beyond my pay grade. :(

Answer 7

It may or may not be. But that's not really relevant. To your end user, crappy UI = bad code.

Answer 8

In my experience it's usually the other way around. You get good quality UI's by having people who spend "huge" amounts of time focusing on widget behavior and look&feel instead of domain model or automated tests.

Some of the best quality systems I've worked with had auto-generated UIs, that were rather unpleasant to use.

Answer 9

No, UI is not indicative of internal code. Many a time's we come across things that are shiny and look cool but serve no purpose. Think of it as a seeing a Ferrari parked at the store. It looks awesome and you wonder what it would be like to get behind the wheel -- only to find out it's a body kit slapped on a 1980 late model Acura that has 500k miles on it.

A personal example, at my current employer, we have stellar code in our software (and I say this subjectively since I was not there for 99% of it's creation). But when you look at our UI, it can seem a bit old and rusty. That and many a times the UI developers don't even touch much of the internal code.

"I'm assuming that if the programmer doesn't care enough to make the outside look good, that they don't care enough at all" - I don't believe this to be true. I think most programmers look for functionality as opposed to shininess as they tend to be creatures of logic, not artists.

Take linux as an example -- stellar internal code, but UI was lacking for a long time, thus why no one in the mainstream has used it extensively as opposed to Windows or Mac.

Short version: !UI.Equals(InternalQuality)