UsWare vs. ThemWare

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.

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.

"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” ?

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?

“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 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 :slight_smile:


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

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


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.