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:

4. 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

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.

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.

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.

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.

It sounds lovely in theory that one should turn ThemWare into UsWare by becoming a user, but that's simply not practical for many situations. Right now I'm working on an app used by parole and probation officers to manage case planning for the offenders under their supervision. I'm learning the business rules and such, but that's a big difference from having gone and done field visits with offenders, who may in fact be homeless, then coming back and performing an evaluation of their rehabilitation needs.

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

This rule is related to Rule Number One from the Cathedral and the Bazaar (see prevalence of *nix comments above). Even if you disagree with the rest of the essay for X million different reasons, this rule is golden.

Just remember that, while making UsWare, you're the most knowledgable and skilled of Us. A great amount of that skill needs to be used in making sure that, as well as being useful and satisfying for you, the software is also usable by the rest of Us.

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

ROFL! Ok, that's the best laugh I've had all week!

Jaster posted the best OSS comment:

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

Jaster on February 29, 2008 04:25 AM

For the past few years, I've been writing software to manage Oil & Gas Reserves. Are you suggesting I should dig a hole in my garden and build a pump jack so I can use my own software and make it better?

LukeB: RE vi: you do know it's 2008, right?

I read a comment by James Gosling last year that he thinks Netbeans is so good now that he'll stop using his favorite text editor for coding. That blew my mind!

Oh, and then I thought:

No wonder James think Netbeans is so good. Coming from a text editor, a 1987 copy of Turbo Pascal would probably be amazing to him.

I'm somehow writing Mainframe Batch jobs...what would that be considered? "ItWare" ? "NoWare" ? "MalWare" ?

"This is pretty much the definition of Open Source software."

Ideally, but I find that a lot of Open Source software seems to be ThemWare, or at least the products look like it. I find it hard to believe that the people who develop OpenOffice.org actually use it to make charts, or to make databases, or any of the other little things that anyone who has experience doing such a thing finds horrific to try and tame.

How many GIMP developers are graphic designers? I doubt many -- the interface is set up like a programmer's fantasy of how graphic designers work. By contrast, Inkscape is actually pretty intuitive, and I find some aspects of its interface design to be vastly, vastly superior over Adobe Illustrator, much better thought out.

(So perceives someone who is about one-quarter programmer, one-quarter graphic designer, one-quarter database designer, and one-quarter academic historian. Meh.)

You didn't mention any UsWare, but I'll mention one from my, now distant, past: COINS. The acronym was, I just went to their site this morning out of curiosity and found that they've been bought by an ex-client, Construction Industry Software.

It was/is written in Progress, at the time a pretty spiffy ChUI database 4GL. What really made it different was the fact that the guy who created it was a working engineer.

Software vendors today write bad software on purpose. The goal is to sweet talk the Users with Eye Candy, thus gaining large amounts of $$$ for the Account Manager, and delivering something which will require large numbers of Off Shore folk to make sort of usable, thus gaining large numbers of Staff for the Development Manager. This is particularly true for Fortune X00 companies, both Vendors and Clients. Neither side of the acquisition has an interest in Good Programming, since GP would diminish the degree of hegemony they would otherwise achieve with Bad Programming. Joel Spolsky (whose site is a measure better than this) has written a few times on this. But I'll claim to have figured it out long before I even heard of him.

Couple that with Users who really think that an Excel spreadsheet is the bee's knees of data structure, and you've got a toxic symbiosis. Kind of like stupid people voting for President :)

Jeff,

Great post, but the issue I see with getting to UsWare is we still have too many old-ish management levels that will say, "I'm not paying you to learn how to use my software, I'm paying you to BUILD my software." I want to create UsWare, but I'm forced into ThemWare by the budget.

Good post, and I must admit that this is very true. When we develop tools that we know we'll use, we really take the time and effort to care that the logic and flow of the program is correct.

This is because we are our own customer, so we _know_ what the program should do and we can refresh the requirements on the fly because the "customer" is there at all times.

Great thesis...

...but as others have alluded to, you need to distinguish between commercial, off-the-shelf types of software and boring-as-hell line-of-business internal corporate software.

In my corporate experience, each hour spent beyond the bare minimum on a boring-as-hell line-of-business application is an hour that could be spent implementing the bare minimum of another boring-as-hell line-of-business application, and the manager who signs off on a boring-as-hell line-of-business application will never actually use said application, and the programmer's compensation is based not on fulfilling users' needs, but by meeting arbitrary deadlines regardless of whether said application works correctly, or even at all.

That said, I've earned lots of points with folks on the "business side" by sneaking in features for them. I'll spend 15 minutes implementing a tweak with saves the users 5 minutes every day, and earn their gratitude, but I can't tell anybody because the boss would be irritated that I was "wasting" valuable time like that.

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

Because NASA has this funny rule about not allowing me to fly the space shuttle. Silly I know...

LukeB: Just because something is "UsWare" doesn't mean it's good for end-users who don't need or want it.

OBSD (and, full disclosure, I've never used it for more than a toy, and never extensively) isn't trying to be UsWare for everyone; it's trying to be UsWare for people who want a secure unix server.

There's more to operating systems than desktops competing with Windows and OSX (and even Linux), just as I don't expect even an UsWare accounting system to be of any use or interest to someone who doesn't want accounting software.

While I agree that UsWare is, in general, better than ThemWare, it can lead to worse software when you aren't aware of your own blind spots.

In particular, if I wrote the software, then I am an expert user simply because I know exactly what the software is doing. I can get around annoyances by using obscure or undocumented features, or by relying on properties of a particular algorithm. And when the display is ambiguous, I don't even notice because I'm not even looking at the misleading part of the display.

Even an expert user who has learned from usage is not going to have the same experience as the programmer.

Having much experience as a BA, one of the misconceptions in the business world is that the more process you add, the better your product.

As difficult as it is sometimes, becoming "one" with the user and having their business processes become part of your life as though you were one of them is, I have found, the first step.

I don't think open source software is necessarily "UsWare." Often it starts out as "MeWare" and morphs into "MeTooWare."

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.

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.

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.

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.

"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."

@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 :P I use the knob when I'm changing volume but it looks better sitting there flush ...

Then there is "UsOnlyWare" which is software that the customers use, the developers use (and write), and the sales and marketing folks have never seen and yet try to sell.

The problem with dismissing so much ThemWare is this: to understand my domain well enough that I can abstract common practices out of it I need to be in that domain for a while, whatever it is (nursing, car repair, hotel management, grocery distribution). Some of those domains require specific training/schooling. Same goes with being a competent software developer. So what's going to give?

...and then there's the issue that being away from that original domain long enough to concentrate on software development means I'm getting out of touch with that domain, the day to day practices that are changing (due to technology, no doubt), and so on.

It's great to develop Us/MeWare, but what happens to the rest of the world?

The nice thing about my employer is that they (the CEO and CTO) were formerly employed by our most major client. Because of their deep understanding of the systems of our client as well as its culture, for all intents and purposes we are making UsWare, in that if there is a gap in our (us devs) understanding of the domain we only have to go up to the bosses to explain things to us in detail.

That this works well in a smallish (~25 devs) company works well for those purposes too, both CEO and CTO are accessible with little or no layers of bureaucracy between us. Not sure if those circumstances would matter if the organization is suddenly quadrupled.

"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.
Jim on February 29, 2008 05:13 AM "

Well, here's a thought, why not sort out a system where you sit next to one of the loan officers (sales) or sales reps, and observe what they're doing? Or set up a system to observe their interactions with the machine, and see what they do most, then have a Q&A session where you quiz them on their activities?
Or go to a basic training class on the software?
No-one's actually asking you to be *good* at the job.

Yes, your Apps will be duller *to you* than 37signal's devtools, but that's why they pay you the moderate sized bucks.

Tom,

Sitting next to someone and observing doesn't make Them into Us. It's necessary to writing good software, but what Us implies, and what "Getting Real" talked about, is the kind of understanding you can only get by doing. I don't think it's a valid argument, but I also don't think you can paper over it by observing and asking questions.

>"I'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.

Correct, but in a bad way: The "Us" is hardcore geeks, and the result is ghastly Rube-Goldberg contraptions that are almost unusable by the general public. The problem here is that programmers are the only users, and they aren't averse to the computer equivalent of rebuilding the engine while the car is speeding down the motorway. Normal users, for some reason, find this a bit problematic. So you have to be careful who the "Us" in "UsWare" is. If "Us" is "other geeks" then you've really got "MeWare" and not "UsWare".

> If "Us" is "other geeks" then you've really got "MeWare" and not "UsWare".

* "OurWare??"

Here's to eating your own dogfood! :)

What Tom said is spot on.

I remember having to take a class in Systems Analysis and Design when I was in college. One chapter was dedicated to gathering information about the project. Of the 7 methods the book listed, 5 of them were gathering information from the users in some way, up to and including watching them work.

"What Tom said is spot on."
What, seriously? 'Cause you should know, I was just talking out of my ass.

I'm really surprised to see Jeff posting this. It's a load of hooey and a common myth in the dev universe. The problem is in the first sentence and not the second.

"The developer creates the software (with with no input from anyone outside of engineering)."

You've already lost the battle.

That idea that ethnographic research can be minimized or eliminated because "we use it too!" is hogwash and only marginally beneficial to the usability of the software. It's one step (not even one full step, a stutter-step perhaps) from "Just think like a user!"

Across 10 years of development at variously sized companies on various products, the only outcome of "dogfooding" is finding a few more bugs.

"The developer creates the software *(with with no input from anyone outside of engineering)*."

Who said that bit in parentheses? That's not in the article.

It isn't in Jeff's post or Eric's article, it's the subtext many read into the idea that if they use the software themselves, they're automagically creating usable UsWare. My overreaction ;) comes from this conversation, repeated ad nauseum at a previous employer:

"I think the GUI should do this."
"Did that come from the field?"
"No, but I use the software and I find it useful."

(typically a feature to aid in debugging during development of the software)

My point: Perhaps more often than not we are creating MeWare rather than UsWare under the mistaken assumption that because we "use" the software, it's UsWare. I feel that some may (mis)interpret Jeff's post with this in mind.

>> If "Us" is "other geeks" then you've really got "MeWare" and not "UsWare".
>
>* "OurWare??"

No, Y'allWare (as opposed to Y'allsWare).

Ack! My nightmare: Jeff makes an entire topic discussing one of my comments, and I don't notice for four days, so I can't defend myself in the ensuing discussion. :-)

I do really like the Me/Them/Us-ware point though.

One "war story" I have may illustrate this. 15 years ago I was working with a group that makes engine controllers for destroyers. They had one system that was meant to be an electronic version of shipboard panel they had that directed the flow of water through the ship. It had sort of a high-level drawing of the piping with switches at strategic points to control the valves that existed at those points in the ship.

The co-worker of mine that was given the task to computerize this panel did just that. He took a photograph of the existing panel and reproduced it on the computer, complete with switches that looked just like the switches on the panel. This is perfect, right? No re-training required for the operators, after all.

I just hated it. Putting myself in the mind of someone using this thing, and knowing what I know about what *could* be done, it's a horrible waste of a potential oppertunity. Think about how you'd *use* this thing. Suppose you try to turn on flow to an area by opening a valve, and nothing seems to be comming out. How do you track down the problem? The best I can think of is to start at the water source and trace your finger along the lines on the schematic, stopping at any closed valves you find. Now how do you figure out which valve(s to use to shut of flow to three specific areas, but not one other area? Sure, that can be trained, but its not so easy to visualise at a simple glance at the panel.

The abstract drawing with physical switches was a pretty good job on the interface back in the 60's when this panel was first designed. After all, they just had paint and pysical switches available to work with. With a computer we can make the interface so much better. Sticking them with the same interface is practically a crime.

So on a week or so of lunch breaks I slapped together my own prototype of the interface. Instead of a colored schematic, this one had colored pipes. Instead of switches, it had actual valves that could be toggled by clicking on them. Most importantly, it showed nice blue water in pipes that were connected to a water source by open valves, and empty pipes everywhere else.

The chief engineer for this engine controller group saw this and went bonkers for it. The quote was something along the lines of "*That* will sell this system". Apparently, unbeknownst to us grunts, there'd been a lot of political machinations to try to get us thrown off the project. Our competitor had created a Windows-based system under an R&D budget for another part of the Navy, and its sponsors in the Navy wanted to see it installed somewhere. If you have ever heard the story about the Windows crash that stranded a US Navy warship, it was *that* system. :-)

Anyway, we didn't get thrown off. I don't know if it was the flow-visualization interface, or the captain using the other system having to get towed back to port. Probably the latter, but I like to flatter myself sometimes.

When 1 company buys another and attempt to develop software together or when your work is offshored and outsourced:

That’s the Them-vs-usWare mixed in with a little of the UnaWare. But always remember to BeWare, but its all starting to WareMeOut.

(i'm not the author, but thought it was true and cute)

> When 1 company buys another and attempt to develop software
> together or when your work is offshored and outsourced:
>
> That’s the Them-vs-usWare mixed in with a little of the UnaWare.
> But always remember to BeWare, but its all starting to WareMeOut.
>
> (i'm not the author, but thought it was true and cute)

Was it Dr. Seuss? :-)

When a Fox is in the bottle where the tweetle beetles battle, and the battle in a bottle's on a poodle eating noodles they call that a ...

@Mike: "I'm disappointed. Not one "WiiWare" joke?"

No, but I was awfully tempted to make a "WeeWeeWare" pun... ;)

http://ferventcoder.com/archive/2007/12/27/problem-solver-or-developer.aspx

I say we are like actors because we need to think like the customers and know as much or more about the process than the customers themselves. We are like method actors as method actors really become the role they are playing. To best understand an issue for a banker, we should really understand things like investments and how they work, and understand paperwork that a banker goes through.

If we don't understand their process/pain, we can't correctly solve it (automate it/fix it) for them. That and customers don't always know what all of their pain points are or don't know exactly what they want. Why would a user not know what all of their pain points are? Have you ever heard the phrase "We've always done it this way"?

If it were up to me, my team would work with (or as) a user of whatever product for which they would be developing a solution. What length of time though? A week? Two weeks? A month? Longer? Preferably long enough for them to really understand the problem domain and have ideas about how to make it better.