![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Programmers to blame for hard-to-use software
Jan 3, 2007 — NEW YORK (Reuters) - Retired microbiologist Diana Westmoreland is no stranger to technology — except when it comes to computers.
"The programs are intimidating. The language that's used is a foreign one to me," said Westmoreland, who lives near Cardiff, Wales. "I'm the sort of person who, when something crashes, apologizes to the screen."
The problem, says consultant David Platt, lies not with the user but with the programmers, who just don't think like the people who use their products.
Platt is a computer science instructor at the Harvard University Extension School and the author of a new book called "Why Software Sucks … And What You Can Do About It," published by Pearson Plc unit Pearson Education.
Read the full article
Oh, WHERE do I begin? This is HILAROUS in so many ways.
As you know, I'm a programmer, and I do a lot of web stuff, meaning I'm spending a lot of time on user interfaces and ease of use.
One of the things you have to attempt to anticipate as a programmer is that people will do things with your code that you never had any idea they would do. Of course, it's hard to anticipate things you have no idea about, so one of the things you try to do is limit the opportunity to do weird crap.
Let's add the security issue into it as well. Sometimes, this weird crap can make your application vulnerable in ways that again, you had NO IDEA it would be vulnerable. A good case in point for that is the mysql database vulnerability. When they were working out the application, they had NO idea that there was a way to allow SQL commands to be added to a web page by a user (the proverbial injection attack). So here's a hole that they can't just close by elminating the command because it's a good, useful command for the programmer and it would cause a lot of problems just to eliminate it.
So complexity begins to pile up. Instead of being able to just close the hole by making it not available, you have to address it in other ways, like by special instructions for handling user input and so on and so forth.
And as it gets more complex, the investment of time required to maintain and upgrade and improve goes up, and that's when the bean counters get involved. They don't want the programmers to rewrite an entire application from scratch--it means all the man-hours used in creating the original application go to waste, then you have to pay for the man-hours to code it from scratch. So instead programmers get told to tack on "features" that "the users want", and this again increases complexity, and the more complex it is, the more potential security holes....
There's a reason the 'Nixes are so secure, and it's not necessarily because the code is inherently better. It's because your average user of any flavor of 'Nix is far better educated in computerese and is more likely to be aware of security issues and potential problems. The more the program is "dumbed down" to be accessible, the more things that get handled automatically, the more likely it is that there will be a hole that someone can exploit. Windows is a memory hog in part due to the fact that they try to automate tasks that the user does for themselves in a 'Nix environment (like assign an IP to connect to the internet, just for example) PLUS all the patching crap they do to try to plug the unanticipated holes PLUS the "features" that get grafted on.
Apple will go the same way if it becomes more popular--more people will be looking for ways to exploit it, they'll patch the holes and add the features and after a while, they will be in the same boat as Windows.
You even see this in Open Source. Code by committee can be a nightmare, ask any person who works in it. You can have hundreds of people working on a single project, every single one of them with their own way of doing things and their own way of commenting or not, and because of the time invested in the core, again, they aren't likely to start it over from scratch but rather are just going to tack on the things that are needed, and after a while, it's like Pero the Chimera from Big O--a collection of varying parts that is very, very scary looking.
I don't know what the answer is, honestly. But the next time you're cussing out a program for not doing what you want it to, I hope you will keep that in mind. Certainly, programs can be made better, but it's not just a matter of dropping a few features and adding a few new ones.
Jan 3, 2007 — NEW YORK (Reuters) - Retired microbiologist Diana Westmoreland is no stranger to technology — except when it comes to computers.
"The programs are intimidating. The language that's used is a foreign one to me," said Westmoreland, who lives near Cardiff, Wales. "I'm the sort of person who, when something crashes, apologizes to the screen."
The problem, says consultant David Platt, lies not with the user but with the programmers, who just don't think like the people who use their products.
Platt is a computer science instructor at the Harvard University Extension School and the author of a new book called "Why Software Sucks … And What You Can Do About It," published by Pearson Plc unit Pearson Education.
Read the full article
Oh, WHERE do I begin? This is HILAROUS in so many ways.
As you know, I'm a programmer, and I do a lot of web stuff, meaning I'm spending a lot of time on user interfaces and ease of use.
One of the things you have to attempt to anticipate as a programmer is that people will do things with your code that you never had any idea they would do. Of course, it's hard to anticipate things you have no idea about, so one of the things you try to do is limit the opportunity to do weird crap.
Let's add the security issue into it as well. Sometimes, this weird crap can make your application vulnerable in ways that again, you had NO IDEA it would be vulnerable. A good case in point for that is the mysql database vulnerability. When they were working out the application, they had NO idea that there was a way to allow SQL commands to be added to a web page by a user (the proverbial injection attack). So here's a hole that they can't just close by elminating the command because it's a good, useful command for the programmer and it would cause a lot of problems just to eliminate it.
So complexity begins to pile up. Instead of being able to just close the hole by making it not available, you have to address it in other ways, like by special instructions for handling user input and so on and so forth.
And as it gets more complex, the investment of time required to maintain and upgrade and improve goes up, and that's when the bean counters get involved. They don't want the programmers to rewrite an entire application from scratch--it means all the man-hours used in creating the original application go to waste, then you have to pay for the man-hours to code it from scratch. So instead programmers get told to tack on "features" that "the users want", and this again increases complexity, and the more complex it is, the more potential security holes....
There's a reason the 'Nixes are so secure, and it's not necessarily because the code is inherently better. It's because your average user of any flavor of 'Nix is far better educated in computerese and is more likely to be aware of security issues and potential problems. The more the program is "dumbed down" to be accessible, the more things that get handled automatically, the more likely it is that there will be a hole that someone can exploit. Windows is a memory hog in part due to the fact that they try to automate tasks that the user does for themselves in a 'Nix environment (like assign an IP to connect to the internet, just for example) PLUS all the patching crap they do to try to plug the unanticipated holes PLUS the "features" that get grafted on.
Apple will go the same way if it becomes more popular--more people will be looking for ways to exploit it, they'll patch the holes and add the features and after a while, they will be in the same boat as Windows.
You even see this in Open Source. Code by committee can be a nightmare, ask any person who works in it. You can have hundreds of people working on a single project, every single one of them with their own way of doing things and their own way of commenting or not, and because of the time invested in the core, again, they aren't likely to start it over from scratch but rather are just going to tack on the things that are needed, and after a while, it's like Pero the Chimera from Big O--a collection of varying parts that is very, very scary looking.
I don't know what the answer is, honestly. But the next time you're cussing out a program for not doing what you want it to, I hope you will keep that in mind. Certainly, programs can be made better, but it's not just a matter of dropping a few features and adding a few new ones.
