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?
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 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.â
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).