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.
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?
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.
Developer dilemma No. 2: How much documentation is enough?
I was sitting in a meeting with an aggressive project manager who really wanted to stick it to a competing project manager. This manager promised that the code coming out of his team would have "documentation," he said, before pausing like James Bond introducing himself and saying, "Extensive documentation."
The only thing worse than no documentation is a bookshelf filled with binders stuffed with extensive documentation. Some project managers love to measure their progress by the pound, and they see more words as better words. Anyone who's slogged through "Moby Dick" in high school English knows the feeling.
We want to know information about the code, but no one has an acronym for Too Little Information. Everyone on Facebook knows the initials TMI.
There is no easy answer for the programmer. Ideally, the code is clean enough and self-documenting enough to avoid the need for long paragraphs explaining just what the code is doing. Code-based documentation doesn't get left behind like text documentation when someone rewrites the code but doesn't get around to the text.
There is hope that an even smarter collection of debuggers and code-analyzing compilers will be able to do a better job understanding our code. The latest versions of the virtual machines keep copious records of which routines are executed. While most of the emphasis is on performance, this kind of meta data can be more useful than real documentation by identifying when data is changed.
But it will be years before we can drink the Kool-Aid and dream about artificial intelligence understanding our code. For now, we're stuck with the problem of how to create just enough documentationto keep everyone happy without shortchanging the feature set.
Developer dilemma No. 3: To the cloud, or not to the cloud?
It's so much easier to call up a new server from the cloud than to fill out a requisition form and ask the server maintenance folks to buy a new one. You push a button and you have your own server.
Alas, this approach can be costly. The servers may be only a few pennies for an hour, but they add up when everyone wants their own cluster for each project. The next thing you know, there are hundreds of servers in the cloud, most of them created by people who left for other jobs several years ago. It's cheaper to keep paying the bills than to figure out what they do.
To make matters worse, the servers aren't your own. Some companies are famous for writing terms of service that are very one-sided, claiming, for instance, the ability to shut down your machines for "no reason." That seems to be changing as cloud vendors recognize that such overreaching drives away the customers with the most money. But no one knows what happens if you encounter problems in the cloud. Sometimes it helps to control the paycheck and retirement funds of the person responsible for the server staying up.
The more you outsource, the more you lose control and spin your wheels trying to recapture it. The less you outsource to the cloud, the more you spin your wheels keeping everything running.
You're damned if you do, damned if you don't.
Developer dilemma No. 4: Maintain old code, or bring in the new?
One of the deepest challenges in running an enterprise stack of software is deciding when to stick with the old and when to switch to the new. Every line of code in the stack is getting older by the minute, and while you might not think so, the reality is that software manages to find a way to go bad, little by little.
The old code really does stop working. Partners start offering slightly different services and sometimes stop supporting features altogether. Twitter, for instance, locked out people who used its old API when the company started insisting on using the OAuth API. These stories are repeated again and again.
The trouble is that replacing the old with the new can be expensive. Programmers of the new are usually forced to maintain compatibility with old code, a challenge that often requires writing two programs: one filled with the old bugs and one filled with new ones that haven't been discovered yet.
To make matters worse, the new code is often held to higher standards. I've seen new fancy AJAX masterpieces that run much slower than old green-screen mainframe code all because they have fancy buttons and tons of images that push the video card. The look is slicker, but the feel is slower.
There is no easy answer to this dilemma. The old code still works. We like it. It's just that it's not compatible with the new version of the operating system or a new multicore chip. The new code costs money. We can usually fix a number of glaring problems with the old code, but who knows what new problems might appear?
Developer dilemma No. 5: SQL vs. NoSQL
There is one big challenge for the database administrators of the world: stick with tried-and-true SQL or switch to trendy NoSQL where everything is bigger and ready for endless streams of data.
The new NoSQL databases sound attractive. They can be much faster than older databases, and they often force users to avoid many of the problems that caused so much trouble in the first place. JOINs, for instance, can slow down a database if the schema gets too complicated. NoSQL tosses them out the window along with many parts of the schema. You can store any key-value pair you like, and the NoSQL database will come up with the answer.
But if you look closely, the NoSQL databases aren't always so wonderful. First, they often don't offer guarantees that the data will be recorded. It probably will be OK, but not if something happens to a hard drive or a computer in the cluster. Some of the newer NoSQL options from companies like Oracle allow you to ask for a transaction confirmation, but your code will need to twiddle its thumbs and wait just like the code that uses a SQL database.
There are deeper issues. Many of the speed problems came about because programmers didn't think about the subtle effects of SQL. The way you structure your tables and queries can make a big difference in performance. Linking together multiple tables and forcing the database to JOIN the information slows things down.
But if you try to accomplish the same thing with a NoSQL database, you'll often be writing data in and out of multiple places and hoping it will all stay consistent. You get to do all of the work of JOINing disparate sections of the database, and that probably means you'll pay the cost in speed. If you are aware of this and are able to think through the trade-offs when designing code, you'll be OK. But if you're not, you may find that your code is even slower and buggier. The database won't enforce the transactions, and you'll need to do it yourself.
This dilemma has a simple answer: Applications that need better consistency should rely upon the transaction guarantees of older SQL machinery. Applications that need speed and can handle a few scrambled records can choose the newer NoSQL datastores. But if you need speed and consistency, you might as well start pulling out your hair.
Developer dilemma No. 6: Go native, or target the mobile Web?
In the beginning, Apple wasn't going to let anyone develop apps for the iPhone. If you wanted to target the iPhone, you needed to write HTML5 for Safari. It was an elegant answer with a well-understood sandbox for developers to use.
Alas, no one was happy with the locked-down platform. People wanted to write native code, a pathway certainly essential for fast games and useful for slower applications that let you browse information. Apple relented, and now we have the App Store.
The trouble is that the code for the iPhone won't work on other smartphones and vice versa. Any company that wants to target multiple manufacturers must rewrite their application -- a long, slow process prone to incompatibilities. Plus, it's double or triple the work.
HTML5 is a nice option. If you can write your application as a Web page, there's a good chance your users can pop them open in the smartphone's browser. There are already a number of great frameworks that make this a bit smoother.
The trouble is that it's not necessarily in the interests of the smartphone manufacturers to embrace this interoperability. If the phones are going to stand out, they'll need to offer something special, and that usually means something different. That won't happen if everyone runs the same HTML5 apps.
There are plenty of rumors that the performance of HTML5 on the smartphones is not as good as it could be. Some suggest that the HTML5 engines are a bit slower. There is no easy way to test this or even understand the motivation behind any sloggy code. In many cases, the HTML5 is slower because it's interpreted instead of compiled directly for the hardware.
The answer to this dilemma is guessing how important performance will be to your mobile app. If it's essential, then custom-compiled native code is the answer. If it isn't, you have some leeway to explore HTML5.
Developer dilemma No. 7: How much control should users really get?
Software users are like teenagers, it's said: They want all of the freedom they can get, but they expect you, the good parent, to rescue them from harm. They want all of the advantages of the walled garden, but insist on being able to slip through some backdoor whenever it suits their fancy.
The issue of control is a difficult one for programmers. The ethos of open source permeates the culture, with its insistence that everyone should be able to recompile the stack and tweak anything to fit. Alas, the average user can't make use of this power no matter how much they want it. Even most programmers have to spend hours finding the right versions of the libraries and the latest edition of the compiler. Control means nothing if you don't have the time to use it.
Some companies are pushing the ideal of open databases. We're all supposed to be able to download the information about us. Alas, most of us can't do anything with the information, and the only ones with the time and energy to use these open doors are other companies.
There is no answer to this dilemma. If you give your users control, they'll complain about the UI and the features they didn't get. If you don't, they keep nagging you for it.
This article, "Top 7 dilemmas facing today's developers," originally appeared at InfoWorld.com. Follow the latest news in programming and mobile technology at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.