Finally, Someone Dares to Say it

From an article highlighted on Digg:

Intelligent extra-terrestrials almost certainly exist on distant planets beyond our solar system, leading British astronomers told the government yesterday.The scientists expect that the first evidence of primitive alien life, such as microbes and vegetation, will emerge within 10 years, with more substantial finds following future space missions.

I can't believe that anyone with a brain larger than the size of a peanut believes that in a universe the size of ours, we're the only planet with life on it. Statistically speaking, the chances are astronomically remote that we're the only planet that harbors life. (Yeah, that's a cruddy choice of words. Sue me later.) It would be the height of human arrogance to think that our world is the pinnacle of evolution throughout the known universe, and to place ourselves at the top of the evolutionary food chain.

But hey, what do you expect from a bunch of talking apes? (Especially a world where the biggest, loudest, most idiotic chimp of all was "elected" the ruler of the most powerful tribe of apes.)

Anyway, when you take into account the size of the universe, and the number of worlds that we're starting to find, the chances of finding one with primitive life begin to rapidly increase. Every time we find a world with primitive life, the chances of finding one with more evolved life forms similarly increases. The further away from our world we move, the greater the chances of finding one with life forms similar to or more advanced than our own.

Does that mean they'll come zipping across the interstellar spaces in vast fleets of gleaming starcrafts to invade or embrace us? Hell no. They'll be just as constrained by the laws of physics as we are. But they're out there. Somewhere.

In my mind, the laws of statistics and probability are every bit as valid as the laws of physics.

read more | digg story

Dew is to Water As Want is to Need

On today's Coding Horror entry, Jeff Atwood brings up a really interesting point about the power of observing users versus asking them. Paraphrased, what users actually want is typically not what they think they want or tell you they want.

It's funny and sad because it's true.

It took me a long time to understand the difference between want and need. I may want a nice, tall fizzy bottle of Mountain Dew, but my body needs water. It doesn't need Mountain Dew. Sure, Mountain Dew tastes better, and I like the fizz, and I look way more cool when I'm holding it, but I don't need it. I need water to hydrate my body and keep me alive. There's a big difference.

Similarly, when users tell you they want a piece of software that does X, Y, and Z, what they usually need is something that does A and B. (Usually, A and B are something on the order of "It works well" and "It doesn't corrupt my data.")

Nonetheless, trying to get users to tell you what they need is akin to extracting molars from a chicken. It's nearly impossible. They'll give you something like this:

• It has to look really good. You know, like SILF. (Software I'd Like to @#$%)
• It has to be fast. Really fast. Like, it has to be so fast that I get whiplash when it starts up.
• It can't hoard memory. Cuz I'm using Windows 98. In fact, can you make it use no memory at all?
• It has to be secure. Really secure. Like, Fort Knox secure. Oh, but I want to be able to pass it around on the Internet and share it with all my friends. Or on a USB drive. Or whatever. Ooh! BitTorrent!
• It has to be a Web app to. With Flash. In fact, do it all in Flash. But I have to be able to use it on my cell phone. And on my XBox. And FireFox. FireFox totally pwnz Micro$oft.
• Everything has to be done in my company's colors: Black and brown. I want all the text in this really cool dark brown color, and the background all has to be black! It's bitchin'! And flames everywhere! And I have this cool soundtrack I want to play throughout the whole thing! And every button should be a different color, and they should make machine gun sounds when you click them! And then explode with a giant fireball!
• I've only got a budget of $500.

Oh, God. The horror. The humanity!

While this list is obviously heavily laden with hyperbole, it's not too far from the truth. A completely user-driven set of application specifications, expressing their wants would likely provide nothing that they needed. At some point, you have to realize that users are, in fact, dreaming about toys.

In the end, software is about enabling users to get their work done faster and easier with a minimal amount of hassle. But users don't know that. Largely, they think it's about fun. Not all software is a first-person shooter or a massively multiplayer online role-playing game. (Sadly.) As a member of a software team, it's our job to identify their needs, and create software that meets those needs without getting sidetracked.

If you're starting a new system from scratch, don't waste your time asking the users what they want. Ask them what they need. Explain the difference to them. (Start by making sure you understand it yourself.) Explain that everything that isn't needed that is added to a product incurs additional cost and delays the delivery of the product, and that someone has to pay for it.

Build systems into your products to monitor which features are being used the most. Don't trust users to tell you. They aren't thinking about it. This kind of information is very useful for determining where to spend your time improving the product. It's also useful for identifying features that you think are critical (in business applications, especially) that should be used, but aren't being used. You can figure out why they aren't being used and target those areas for resolution.

If you write a solid subsystem like that for your software, you won't have to rely on user feedback, which isn't always reliable. A solid monitoring system will not lie to you. And that information will help you make much more intelligent decisions in the future. It's a question of silently observing the users as they actively use the product, instead of asking them about it after they've done so. All of us have a pretty short attention span when it comes to software use. I have no idea what the most used commands are in any given software package based on my own usage scenarios. For that reason, you couldn't ask me to tell you what commands or features I use and get a meaningful answer from me.

So think about whether or not you need it. If you do, invest the time to do it. But don't do it because you want it.

Dew? Or water?