IT people have a tendancy to only compare software in functional terms

Criticism should be a positive thing. Not personal attacks or trying to put people down. It should be about identifying opportunitites for improvement. With that in mind...

IT people have a tendency to think like this:

Pieces of software have a function.
For example. Programming languages are for writing programs.
Utilities like ‘ls’ or ‘dir’ are for giving you information about the file system, as are graphical file browsers like Windows Explorer.

Comparing programs means comparing their functional capabilities.
(Many times, I've head people dismiss programs or programming languages because other programs can already do the same thing.)

But this way of thinking overlooks usability and other "non-functional" (which is a bit of misnomer) issues.

Sure, you may be able to do the same things, but can you do them as easily? If usability wasn’t a factor, people would be happy to write all software using Assembly language.

The notion of a language being ‘easy’ (or ‘hard’ to use) is itself a simplification. Easy or hard for what? There’s always some sorts of tradoffs. Easy for systems programming? Easy for writing simulations? Easy to write? Easy to maintain?

'Easy' or 'hard' is in the context of using a particular program for a specific task a person is undertaking. The can a complex set of factors involved, including the nature of the task and of the person doing it. Here are some basic examples.

Comparing information is easier when the pieces are closer together. The further apart, and the more actions like mouseclicks you need to perform to navigate between them, the tougher it is on your concentration. When you're thinking and your train of thought moves, you want to be able to nimbly adapt the information display, such as changing the ordering of the information from alphabetical to chronological.

Time is an important component. We have limited ability to keep track of things over time. Getting the pieces of information in quick succession is quite different to getting them many seconds apart.

Why are IT prone to thinking of computer systems in this way? Well, in part, it’s nothing specific to the nature of IT people. I think we all tend to see phenomena in ‘functional terms’, and tend to overlook the other aspects to them. And, as I've said before, we tend not to factor in constraints into our conceptualisation of things, and are poor at doing it when we try.

The thing that's different about IT people is simply that they explicitly think about and compare software more than non IT people do.

A contributing factor in the case of systems whose functions it is to present us with information is a simplistic notion of perception. In this view, perception is simply a matter of taking in information, and what we end up with in our heads is simply a reflection of what is out there. The thing is, our perceptual/cognitive systems are highly structured, and constrained in various way.

This is why you can have the same information can be much easier or harder to deal with, depending on how it is respresented and/or how you can interact with it. Our brains look for certain cues, and whether they’re there or not makes big difference. They have all sorts of built in assumptions, expectations and limitations.

Revisiting the question of why IT people see software in this way, there might be one factor that is specific to them. IT people in particular see programs in this way. They're used to thinking of how to use software to solve problems. With a program, as long as it can get hold of the information it needs, the original format doesn't matter so much, as it can then put it in a more usable form, and then solve the problem. The difference with our brains and perceptual systems is that they have more limited capabilities to do this, and to do this fast enough for it to be practical. Our hardware is much more dependent upon the external format.

We don't just compare software that exists. When someone thinks of an idea for a new piece of software, it gets compared with what we've already got. So this issue of how we compare software applies to developing new software. If we can be aware of the problems with only doing functional comparisons, we won't be so eager to shoot down new software, for even the best new software rarely does anything new in functional terms.