UsWare vs. ThemWare

MeMeMeUsWare can sometimes look like UsWare. The difference is that some weird features only make sense if you use it all the time and have years of familiarity. But it still beats NotMeWare.

Manufacturing Test Fixture software is the worst. You are on a moving target aiming at a moving target … and the customer is always pissed off and behind schedule.

Your right. UsWare is likely to be better than themWare. Having end users involved in prototyping and testing early on do help to bridge the gap. A good test plan that captures how they use the system and what data they use and results they expect might help too, but that would require effort on our part! Sometimes that is as close to dogfooding as you’ll be able to get.

Having lots of options available usually means you’ve given up on design decisions and left everything up to the user.

Product manager: “The volume control should be a knob, it’s easy to understand and easy to operate.”

Industrial designer: “Knobs are so 1970s. Let’s use flush-mounted buttons with these elegant little arrows in them, it will look so much better.”

Design engineer: “Argh I can’t choose. Here, I’ll just make the radio have interchangeable faceplates and the customer can decide which one they’d rather have.”

And if you’re sitting in a conference room trying to pick between these options, there’s no way you’re going to make the right decision. You have to actually use the thing you’re building and it should become apparent which is the more appropriate choice, and you can eliminate the configuration step for that particular choice.

Most Open Source software is actually more like me-ware. (Hint - the command line is not a user interface.)

Hey Now Jeff,
UsWare, I never heard the team before but sure do like it. I’m convinced more than ever UAT (uaer acceptance testing) sure is important in the life cycle of software.
Coding Horror Fan,
Catto

@Rich:
Yes, that pretty much is why it isn’t ready for EVERYONE’s desktop.

It has been ready and working far more productively than Windows for me for 4 years now. I hack on a few OSS projects, KDE being the biggest and I work on “Usware” projects that I and others will use. However I don’t need things like automatic X server configuration or GUI replacements for some perfectly good console applications so I don’t write them and that is why Linux is best for programmers on the desktop.

I think it has reached the stage where people cater for the novices so my parents can use Linux fine but Windows power-users tend to struggle because everything functions very differently from Windows.

I work on a trading platform for a bank, so making it UsWare would require getting us proggies to bet millions of euro’s on the stock market. Oooooh I soooo want to do that!

I’m personally more motivated to create UsWare and MeWare than ThemWare. There is no excitement in creating something you aren’t passionate about. Unfortunately, ThemWare is how I get my paycheck, so I will keep making ThemWare.

“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 think you may have got that wrong:

http://en.wikipedia.org/wiki/Eat_one’s_own_dog_food
"The idea originated in television commercials for Alpo brand dog food; actor Lorne Greene would tout the benefits of the dog food, and then would say it’s so good that he feeds it to his own dogs."

In my experience, this is one of the advantages of open-source software–nearly all open-source software was developed because the developers personally had a need to use it. Some of it starts out as “MeWare” and becomes “UsWare,” and some of it was always intended to be “UsWare” in the first place (which does usually lead to slightly better software). There is almost no “ThemWare” in the open-source world.

On a separate topic, I think a lot of the commenters do have a point that some software is much more likely to be ThemWare than UsWare. Although it’s certainly possible to be an accountant and design a system for accountants (and I’d recommend that at least the lead developer of an accounting package have that experience), many of the programmers won’t have any idea what the user’s world is like. I think in that case, it’s important to have some form of constant connection to users, to listen to what their experiences are–not necessarily to listen to their advice on how to fix it, just to have an understanding of what their world is like.

-Max

I agree only partly with you, often to be developing usware or meware is a good excuse not to produce good documetation.This works well, until a new developer join the group or, worse, somebody leaves it.

Code gets developed fast and well when developer sits right next to user. One consequence of such an arrangement is UsWare, but lots of other good things happen. Feedback loop is much tighter, change impact is understood better, etc. Everything works better.

I don’t feel that programmers use software the same way as the average non-techy user. I mean, look at development environment programs - they are a dream for a programmer to use with all the different functions (debugging, projects, inspectors, DB Connections, etc) configured to show up just about anywhere, with hot keys for every function, macros, etc. But to the average user all of this would just be confusion and clutter. They don’t live in the same world we do.

Another example is vi - for someone who spends a lot of time on *NIX and knows all of the keystrokes, vi is a powerful tool. To the average user vi is completely alien.

How can programmers, a group of people that create things for themselves like development environments, use the program they are writing and expect to be able to enhance the user’s experience?

@Steve, @Jim

One technique that works for me in situations like that is to force a demo. See if you can get together some people, preferably some outside your team and then you, the developer with presumably no sales skills, have to convince the crowd how useful it is. At least for me, trying to convince someone else to use this pile of steaming crap helps bring home what might be done to improve it.

I can’t remember the quote, but something about you don’t know what you don’t understand until you try to teach it to someone else.

UsWare is the best? The shining example of UsWare is the OpenBSD project, which has produced excellent, securely-written software, but it is totally unusable by the general population.

The vi example is perfect as well: I think it is one of the most powerful programs out there but it is foreign to both normal people as well as most programmers!

On a stylistic note, I must say that your use of em-dashes bothers me. I believe the proper usage to be “some stuff–other stuff”, but you use it as “this stuff-- that stuff”.

Otherwise, hooray for UsWare! I always try go beyond what the users say they need to find out why they need it. If I can understand the underlying process, I may even be able to suggest a more efficient solution.

@Jake Cohen
Heh, my car radio has a knob AND a flush button - I simply toggle which by pressing the knob/button and it either locks in flush or sits out as knob :stuck_out_tongue: I use the knob when I’m changing volume but it looks better sitting there flush …

Jeff, terrific post with a catchy take-away. I am now doomed to linking to you whenever I use the words “Usware” and “themware.”

:slight_smile:

I fully agree. It’s tough to take off the programmer hat and turn yourself into a parallel end user, but it’s what needs to be done to keep everyone happy. And quite frankly, it is my least favorite part of software development. I’d love to create nothing but MeWare, but that would be pointless.

“Morphing” into a true end user is a skill in itself that requires patience and poractice, and is just as crucial as modern coding conventions (IMO).