UsWare vs. ThemWare


#1

Ted Dennison left this astute comment in response to Do Not Listen to Your Users:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/02/usware-vs-themware.html

#2

I’m sorry, but I just gotta ask.

What’s the difference between “some stuff/other stuff” and “this stuff/ that stuff”? I can’t tell.

Maybe I had to be there.


#3

The big one why UsWare is not always a good idea: the users have a good reason to use the software. They want to get their job done, efficiently. I, as a developer, can’t learn that job in some months. I even don’t want to! Am I interested in managing a bookstore? A takeaway service? A steel mill? No. And for most users, the sorftware is only a tiny little bit of their daily work: they want to sell books, make pizza, cook steel. None of that is my job, I have no intention to make pizza for a week just to get the users perspective. I hate making pizza, I love making code, and the customer will never pay my developer priced bill for making bad pizza. So I simply can’t work from the same angle.

Work with the users hand in hand. That’s almost always the best you can get.


#4

I’m disappointed. Not one “WiiWare” joke?


#5

I know there are a lot of companies that have taken users and turned them into programmers for one reason or another, when the products are internal. It’s always nice to have user input when creating “Themware” (which most of us have to create at least once in a while if we get paid to write software), but it helps if the users actually have something helpful to say. I generally find that I have to at least get something up and running before I ask for user input, and even at that point they tend to be vague, at best, or will say that whatever I have is fine, even when they’re having trouble with it.

I also find I have trouble convincing management that it makes sense to spend more time and money on the software to improve the user interface or add a couple more features to something that has the basic functionality they defined as the project’s goal at the start.


#6

So true…

I work as a developer on a very big ERP project, but we never really use it outside of our test environment.

On the other hand, we have a very different eye for the internal tools we develop and use.


#7

“'ve found that much of the best software is the best because the programmers are the users, too. It is UsWare”

This is pretty much the definition of Open Source software.


#8

I’m sure there is a lot of ‘bad ThemWare’ that is a result of poor UI specifications which are forced onto the developers to implement.

Caring about something you know is wrong can be bad for your blood pressure.


#9

You forgot one:

  1. Shiteware

Nobody uses it.


#10

And then there’s ManagementWare. It’s the worst of them all. Programmers develop the software according to Management specifications for User to use.


#11

Then there’s ‘Committeeware’ - software designed by committee to be everything to everybody.


#12

“I’ve found that much of the best software is the best because the programmers are the users, too. It is UsWare.”

How do you explain version control software then? :slight_smile: It’s pretty universally dreadful.


#13

Having to actually use the software you write is the best way of making it usable, but beware I help write softare that we also use, but we don’t really care if it works or not (it’s not required!), so it does not work very well…

…and beware of developer friendly user interfaces that bemuse the customer (this happens far too often in OpenSource projects)


#14

“Why work against your users by producing ThemWare when you could work alongside them to build UsWare?”

Because, unfortunately, most software created these days is enterprise accounting systems.


#15

Nice new font, looks terrible without Cleartype though…


#16

“This is pretty much the definition of Open Source software.
Mark on February 29, 2008 03:38 AM”

Can’t resist: I guess that’s why linux is still not ready for the desktop then…

(Ducks)

Rich


#17

Great blog post! Coincidentally, it explains why I absolutely despise the term “dogfooding.”

“Dogfooding” implies an attitude that software a software developer create for others is generally software they wouldn’t use themselves. “Ick, that’s dogfood! Don’t eat it!”

I like the old Remington Shaver slogan: “I’m not only the president of the company, but I’m also a client.” That presents a more sympathetic attitude about your products and your attitude towards them.


#18

Too much UsWare looks like a programers wet dream. “Wait, I have how many options! GREAT!
{click}{click}{click}{click}{click}{click}{click}{click}{click}”

Take a look at PSPad. A great program, but you can get totally lost in the configuration.


#19

I remember when I was designing a program to process text files with a certain text in them. Basic as it was I was going to be using it too, not just my friends who wanted it. So while using it I found easier ways to do things, knew what information should be given right up front and not to hide anything in menus that take up to a minute to browse to.


#20

I agree with Steve. I work for a large financial institution. The software is loan origination and servicing, receipts and disbursements, etc. There is no way to share the user experience except to become a loan officer (sales) or service rep in a branch office. “Dogfooding” works for dev tools and for general apps - word processing, spreadsheets, email, browsing, social sites, etc. It doesn’t work for complex software systems in specialized areas where the typical user in that area is not technical (so there’s no chance of picking up talented users and making them programmers - unlike, say, software for various forms of engineering). That isn’t meant to sound elitist.

So I can read “Getting Real” and look at 37Signals products and see how they can be all excited about using them themselves because they’re general purpose tools. I just don’t see the argument working much when designing back office systems, ERP, loan retail system, etc.