"It's hateful when a developer takes a 'shortcut' that saves that individual a couple of minutes, but thereafter causes extra effort from every single user. Awful as they are, these application design errors - all the fault of lazy developers - are entirely too common."
To read all comments associated with this story, please click here.
Member since:2005-07-06
I think much of the problem is the attitude of which you are displaying an excellent example.
You seam to see the software Developer as a person who writes (insert your favorite programming language here) code. This person might be very good at that, but that doesn't make him a good software developer, at best it makes him a good programmer. As such he is a very valuable resource to the project, but he is not the only resource needed for a succesfu project.
Modern software projects are far too complex to be handled by people with just one skill, and in most cases you need to engage more than one person to get the level of expertise you need.
E.g. an expert in software design may not only help you design code that is fast and works well, but also design it in a way that it is maintainable, testable and that you easily can add more people to the project in case it grows. That person is not necessarily the same person that is ũbermench at getting the details in the C code just right with impeccable precision.
You need people that can express themselves well human languages to write documentation. If the programmer writes the end user documentation himself he is too close to the project and he will take too much for granted. E.g how many times have you seen descriptions of flags to Unix/Linux CLI programs that tells you that it is used to specify a file size, but it doesn't say if it is in blocks, bytes or something else. To the programmer this is obvious, but not to the user.
You need artist that makes your ikons and other graphics in your software to look good and consistent.
Just like you need the skills mentioned above, you need skill in e.g. usability to help the programmer to make a program that interacts both effectively and efficiently with the user. The things that are important to the programmer might not be all that important to the user.
One typical example of this is GUIs like Gnome and KDE. They both try to be as good user interfaces to Unix as possible, and this might be a good thing if the intended users was sysadmins, or developers. The problem is that in most organizations these roles are in minority, as they just provide services to the people who do the real marketable work of the organization.
So why is it that both KDE and Gnome insists on showing directories like /etc, /proc, /usr, /sbin, /bin, /dev, /sys, /lib to the accountants, salespeople and other people with non computer related jobs that are the most likely target user of the system. The only reason I can think of is that the Programmers/Developers want to show that it is Unix. However, to the accountant or salesperson Unix is most likely irrelevant. This is probably why you don't see these directories displayed in MacOS-X, and in turn, the reason for that is most likely that Apple hires usability experts who can give their programmers good advice in this kind of matters.
All in all, good software development of any non trivial piece of software is teamwork, and all skills are equally needed. Programmers as well as usability people.
Member since:
2005-11-14
Think Monk on a PC and you have a usability expert. Developers, thank goodness, do not have to listen to usability "experts" too often or there would be no software as we would have all shoved hot burning pokers through our eye sockets by now as a result of your incessent nagging. If you don't like it "expert", don't use it. Enough said....