Why sharks dont have laser beams

By Iz Derdik on December 03, 2007 | 2 comments

Hi! My name is Iz and I'm a technoholic. I love reading about technology, tinkering with hardware and most of all - I love buying gadgets. Unfortunately (or fortunately - depending on whether or not I have to clothe and feed you) I'm also extremely... er... let's call it frugal. It's not that I'm flat out cheap, it's just that I know the difference between want and need. I want a big-screen, surround-sound home theater system that can be controlled by an iPod Touch. However, I realize that all I need is a dedicated 20Mbps symmetrical fiber optic line to my house and a computer to access it on. See? Its simple!

However, the line between want and need can get blurred when an item in my want column suddenly goes on sale. For example, the iPod Touch that I want is currently out of my range at $300. If for some reason, Apple would decide to slash prices on the coolest MP3 player in history and suddenly make it $200, that want becomes an Itch. Make it $150 and - boom - now I need it!



At this point you may be wondering, "OK, you like toys but are too cheap to pay for them. So?" Well, building software comes down to a lot of the same choices and thought processes as buying crap. The touch-screen, refrigerator mounted, tablet PC becomes a feature that you may or may not implement. On the one hand - it's cool and some of your users may love it. On the other hand, many of your users won't care and implementing this cool feature may push your release date back a few weeks.

Sometimes, we have the real world equivalent of a sale: The situation changes making it more practical and inexpensive to implement a wanted feature. Scenarios include user feedback, competition or a technology breakthrough... anything that lowers the cost to (or raises the price of not) adding the feature. Suddenly, the want becomes a need and will make it into the next release.



The fun part - at least for the coders, is the actual design and implementation of the feature. Careful consideration of methodologies employed in producing the feature comes into play and this is where the programmers are supposed to shine. A good programmer keeps a need from sliding back into the want column, by making the most functionality using the least amount of resources possible.

So the next time you wonder why every household doesn't have a floor-washing robot, your favorite mp3 player doesn't have an FM radio or why your online word processor can't handle outlines, think about whether those products or features are actually needs or merely wants and you can understand why they were included or left out. At the very least, it will help you crystallize an explanation to your spouse as to why you need a PS3.

< view newer posts | view older posts >