UsWare vs. ThemWare

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

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.

“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 :wink: 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.

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

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

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 RD 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. :slight_smile:

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.

If “Us” is “other geeks” then you’ve really got “MeWare” and not “UsWare”.

  • “OurWare??”

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

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

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… :wink:

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.

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.

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.

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.
More of these here.

When you do or create something you like it is always reflected in the product.

I wanna recognize EGOware, DEMOware and WTFware.
These products might not be used by any users, but they exist to please someone, get next funding slice or just being unusable.

1 Like