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.