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
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/02/usware-vs-themware.html
1 Like
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.
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.
Iâm disappointed. Not one âWiiWareâ joke?
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.
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.
â'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.
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.
You forgot one:
- Shiteware
Nobody uses it.
And then thereâs ManagementWare. Itâs the worst of them all. Programmers develop the software according to Management specifications for User to use.
Then thereâs âCommitteewareâ - software designed by committee to be everything to everybody.
â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? 
Itâs pretty universally dreadful.
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)
â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.
Nice new font, looks terrible without Cleartype thoughâŚ
â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
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.
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.
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.
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.