02.07.07
Writing software my friends won’t use
It sounds wrong, doesn’t it? I mean, if my friends don’t want to use this version of AIM, is it really going in the right direction? But a question that seems so easy to answer, really is kind of difficult.
With a big rewrite like AIM 6.0, some features slipped through the cracks. I assumed these features would be added at a later date, especially ones that are in high use. For example, just about every person I have talked to who doesn’t use AIM 6 is stuck because of one key feature that hasn’t been ported from 5.9. This is actually a great feature and is all about sharing and communication. So it only makes sense to add it back in, right? Well, what if the powers that be decide that adding new features (that my friends probably would never use) are more important?
It’s quite a paradox. I mean, we all want to write features that we think are fun and interesting. The unfortunate reality is that developers aren’t really a good representation of the user base for a product that is used by over 60 million people. On the other hand, no single group can be. Developers DO generally know the product well enough to be aware of strengths, weaknesses, what is possible and what is not so easy. Furthermore, if a developer is checking the pulse of the community (which does include his friends), he should have an idea of at least a couple features which are mutually beneficial. So what is a developer to do when the product direction is one he doesn’t agree with?
Corey said,
February 7, 2007 at 8:47 am
There’s a term we use for developers here at Revolution that take matters into their own hands for the betterment of the product. Ninja. A developer is said to have “ninja’d” a feature if he spent a night or two of his own time building in something super cool that product couldn’t “afford” to spend cycles on.
Ninja those features you’re missing!
Osman Ullah said,
February 7, 2007 at 8:52 am
Ahh yes, when I was working on AOL Explorer the UI lead on the project had his own term for it “rogue developer”.
But that requires the developer to have time on the side.