We're gonna implement that cool feature! Great, but who's gonna use it?

Assume you're a programmer, part of team A to develop product B. You have release X.Y.Z coming up in 2 months, and there's plenty of features to develop. So, lets make up the list of features to develop, for release X.Y.Z.

A lot of companies these days are democratic - they will create some great meeting(s), involving all the team, and then deciding what (features) to implement next. Then, go ahead and do them, and as release approaches, well, just drop some features (those too hard to implement).

Sounds (too) familiar?
Well, I'm here to tell you - it's wrong!

No matter how democratic a company is, when deciding the features to implement, this should be up to the User Experience department.

Why? Because programmers will just choose the features that sound coolest for them to implement, not with the benefit to the user in mind. It's very hard for a programmer to think like a user, and even if you think you do, you're too close to the code.

The features should be in line with your customers' needs, and the priority of the features should always match those needs.

The challenge for you, the programmer, is to make it happen. It's good to be under a bit of pressure, so that

• you'll talk to the User Experience department to understand what this feature offers the user, to implement it right
• you can focus on using the best tools (as opposed to subjective thoughts like, I'm not using Language X because it lacks A,B,C)
• you can shift focus on getting things done. We programmers tend to spend a lot of time blabbering about which technology is cooler/better/etc. - but it doesn't matter. You first need to understand the problem, and then choose the technology you'll use to solve it (not the other way around)