Your boss wants it yesterday, but it better be good when judged by the standards of tomorrow. Your customers want every feature they can imagine, but don't you dare confuse them by giving them all the buttons they want. Your fellow programmers want your code documented, but they just respond "tl;dr" to anything you write.
As technology evolves, so too do the dilemmas developers confront. Every choice, from platform to data store to how much control to give your users, is fraught with questions. And thanks to the cloud, the rise of mobile tech, and the hastening cutting edge, it seems as if the programming world faces a new choice -- and dilemma -- at an increasing pace.
[ Beware the 7 myths of programming, and verse yourself in the 10 hard truths developers must accept. | Test your programming smarts with our programming IQ tests: Round 1 and round 2 and "Hello, world": Programming languages quiz. | Keep up on key application development insights with the Developer World newsletter. ]
Packaging your problems and giving them a name can help you manage them and maybe even find solutions, or so they say. Toward that end, here is a list of the most significant dilemmas facing programmers today. It is by no means complete -- then again, what project related to application development ever is?
Got another dilemma? Add it to the comments.
Developer dilemma No. 1: When to say when on feature requests
If we had a dollar for every feature our customers wanted, we'd still be broke because that would require building an accounting system that matched each dollar with each feature. These would then need to be cross-linked and prioritized because our customers would also demand a sophisticated bug/feature management system for their dollar. Then the database of wanted features would need to be backed up to some cloud and translated into every language.
This is the dilemma: Everyone wants feature-rich code, but no one wants to pay the cost of managing all of it. Anyone who's tried to build something as simple as a four-button remote control app knows how many zillions of designer years it takes to create something that simple. Making something elegant requires sweat that soaks through everything.
Consumers, the marketing department, sales reps in the field -- it doesn't matter who makes the request. Giving them the button they want may actually be the worst thing you can do for them. Suddenly there might be too many buttons and too much confusion about what each button does. The ideal is to make something easy enough to understand intuitively, but alas, creating something intuitive for those who are prone to ask too much of their software is all but impossible.
You've tried quoting the old "rule of 10,000" to your boss. This states that anything worth doing requires at least 10,000 hours of work to become competent. That just brought a laugh because that app store customer or coworker in accounting is going to spend more time drafting a nasty review or email than trying to understand the features you've collected in your app, even if they're features the users said they want.
Sadly, the ideal can often be to convince your customer they don't actually want the feature they've requested. After all, Twitter continues to offer a feature-poor system that imposes a 140-character limit, laughable in the era of terabyte disk drives. Yet it sails on, serene in the knowledge that all those attempts at providing new features are examples of trying too hard.
If only this solution to the dilemma of unending feature requests was available to us all.