I see in Eich's comment where he talks about a site "foo.com" including content from a separate domain "foocdn.com" belonging to the same company. My question is why they're using a separate domain? Why not "cdn.foo.com" which would automatically indicate that this domain's part of "foo.com". Or is this a case of "Doc, I don't want to stop hitting myself in the head with a hammer. I just want you to make it stop hurting."?

First rule: if you're routing your traffic through someone else's infrastructure (in this case MS's Skype servers), they are monitoring it. The only way around this is client-based encryption where the infrastructure in between doesn't have access to the encryption keys.

Second rule: if the encryption setup requires someone else's servers to be involved, they do have access to the encryption keys. The only way around this is to either have the clients communicating directly or to use a key exchange protocol that's resistant to eavesdropping.

Third rule: if you're truly concerned about confidential information, you shouldn't be depending on someone else's infrastructure in the first place. It's something you don't and can't control, which means using it's an inherent risk that should be avoided if possible. Get hosting or set up a server in your data center and run your own servers.

That Skype chat's monitored should come as no surprise. MS will monitor Skype and MSN's IM service (whatever they're calling it this week). Google monitors Google Voice and Chat. Facebook monitors Facebook Chat. Your e-mail provider monitors your e-mail. If you're worried about security or confidentiality, acknowledge this and take appropriate measures.

It goes deeper. Think about some of the business-critical applications that a company might have. Business-critical in the sense of "the paychecks don't go out if these aren't running". And they were written over a decade ago for J2EE 1.2 using technologies nobody uses anymore. Nobody in the IT department understands them anymore. They can't find contractors to work on them. The last batch that tried broke it so badly some of the bugs are still hanging around (reverting everything didn't fix all of them for some reason, probably somebody missed a file somewhere). It's not just the code underneath, it's all the cruft in the Web pages the application serves up that's so incredibly specific to IE6 that it just won't work elsewhere. And there's more than one of these monstrosities lurking around. The company isn't even sure how many. They keep turning up in the oddest corners, written to serve a purpose and forgotten about because they do their job and were never formally documented anywhere.

And here's the catch-22: none of the more modern replacements will work with IE6. The company can't replace all these applications at once, aside from the huge costs there's the fact that they don't know if they've got all of them until something breaks. And they can't afford breakage, if these things don't work the company stops working. If they upgrade to a more recent version of IE they know something critical will break and shut them down, but if they don't upgrade they can't put the newer stuff in service.

Just console yourself with the thought that it could be worse. Think COBOL, and why IBM mainframes can still run 1960s-era System/360 binaries.

Worst is the potential for disruption of work. With the non-cloud model, users can upgrade on their schedule. If they're in the middle of a big project, they can postpone upgrading until they've got a few weeks of slack time. With the Cloud version it'll be very easy for Adobe to force upgrades when Adobe, not the user, wants. You can imagine the headaches that could create.

I'd write it out longhand (2 modulos, then a 4-legged if/then/else block using the modulos) to make sure the logic worked, then compact it to the case version for performance with an explanation of why it worked so I'd remember what the real requirements were when I came back to it.

And the last depends on the language. In C/C++ integers can be interpreted as booleans with 0=false and non-0=true. I think the same holds for PHP, Ruby, Python and a bunch of others. In C# I believe you have to use a boolean operator to test to get an actual usable boolean, ie. what in C++ would be "if ( m )" in C# would be "if ( m != 0 )".

If your company's making software or selling services based on software, it may be that it's not that sales is high but that engineering's artificially low. Non-labor costs for software development are low. A few thousand dollars for office and computer equipment per engineer (which is a one-time expense, you don't have to buy new equipment when one engineer leaves and you hire another), a few thousand total for printers spread across all engineers... after the first purchases when you start up the annual costs are surprisingly low. Most of the cost will be salary and other labor costs. Sales requires printing of marketing material (which probably has to be farmed out because the specialty equipment isn't something most businesses can justify buying themselves), phone and postage and other costs related to contacting customers, costs of flying salesmen out to talk to customers or negotiate contracts, costs of booths and supplies for trade shows... And it's all recurring costs, spending the money this year doesn't get you out of spending it again next year.

For fossil fuels, the extraction rate far exceeds the replenishment rate. Usage will only go up as more countries develop economies that demand more fuel for transportation, more electricity and more raw materials for synthetics. That means that the supply will eventually be exhausted. We can push the date out by finding more supply, but there's a finite amount to be found and it's going to be harder and more expensive to extract as time goes on (because the easier, cheaper stuff gets found and exploited sooner). Eventually though we are going to hit a hard exhaustion date where we just can't find any new supply. When that happens, do we want to have alternatives in place and ready to go with minimal disruption? Or do we want a mad last-minute scramble to replace everything on short notice and with no prep time?

What prevents people from copying books, or CDs, or magazines, or newspapers, and giving them away willy-nilly? Yet writers and artists and photographers have managed to make a living despite that.

The problem is that DRM only addresses half the issue. It ignores any rights the owner of a copy might have, and declines to enforce those rights against the copyright holder's infringement on them. As long as it does that, it serves no useful purpose from my standpoint. To be useful to me, a DRM system would have to manage and enforce all rights, not just one party's.

My understanding is that if you just buy phone service there's no early termination fees at all. That "early termination" fee only comes into play if you buy a handset at the same time and elect to pay for the handset in installments. In that case they'll include the installment payment for the handset on your bill each month as a separate charge, and if you terminate service you're responsible for paying off the balance of the contract for the handset. But that's hardly deceptive, I mean when was the last time you financed something and could just walk away from the contract early without paying off the remaining balance? The only thing unusual here is that there isn't an option for continuing to pay the installment contract for the handset when you don't have phone service and so aren't getting a regular monthly bill. The AG might be able to make a case for tying the handset payment contract to continuing phone service, but I hardly found the terms of the deal deceptive and certainly not hard to understand.

I notice that these days the pendulum is swinging again. Away from thin clients that just render what the software sent them. Towards thick clients running on the user's PC that handle the bulk of the processing, talking to a remote server to get the data and then using that data in a local program. The programs are written in different languages, Javascript instead of C/C++, and the data's XML rather than the various formats of a couple decades ago, but we're swinging back to the PC running the programs instead of them running on the server.

So why aren't we just admitting it and saying "Our data's XML, you're going to need our software running locally to interpret it."? That's what non-standard application-specific "markup" languages would be, data that's meaningless without the accompanying program to interpret it.

You can have confidence in your estimates and still be aware that that confidence is misplaced. One of the common things I keep saying to my manager is "Yes, I'm pretty sure we can finish this in 3 weeks. But I want to schedule it for 6 because always, always we spend half our time getting pulled off onto other things and I want to account for that now before we get in a bind.". I have confidence in my estimates, but I also have confidence in the statistical evidence of how reality varies from my estimates and I'm not prepared to ignore the latter.

As others have said, I also end up in arguments where people "up the chain" have already decided when they want something delivered and are pressuring me to make my estimates conform to the schedule they've already set. I don't consider this a problem with my estimates or my planning/scheduling, because I have no input into this or ability to control it. The problem lies with the people who're making promises without making sure those promises can be made good on, who then expect someone else to pull their chestnuts out of the fire. I can't do anything about that, because I can't order them to ask for estimates before setting delivery dates.

More than that, they should adopt the "no single-source systems" approach. Don't adopt data formats that're only understood by one product. Don't adopt products where support is only available from one vendor. That way you won't be in a bind if a vendor ceases to support a product or tries to jack up the price on you or goes out of business.

So, on the UI side, how do you solve this problem: I have a Visual Studio window, a database access client window, 3 Web browser windows and 4-5 command windows of various types. I need to see most of those windows at the same time because I'm either working in them or referring to them while I'm working. Yes, I have the monitor space for this. How do you do it?

Note that saying "Don't do that." isn't an option. I'm not going back to printing out reams of paper so I can refer to reference material while I'm writing code.

Windows is dead in the same way COBOL is dead. Windows 7 and earlier have too large an installed base. Even if Windows 8 flops and Microsoft can't recover from it, the Windows and Office and IIS and SQL Server installed base will insure they've got a revenue stream for years to come. And Windows 8 isn't going to be an unrecoverable blunder, Vista proved that. At worst MS will tweak and fine-tune Win8 and Metro and turn it into a phone/tablet OS, with Win7 continuing as the desktop OS and Windows Server 2008 and 2012 as the server OS.

This of course is where MS's emphasis on integrating everything hurts them. Taking Windows 8 and slapping the same UI as Windows 7 on it would solve a lot of their problems. But because of the tight integration, they can't just do a forklift upgrade of the Win8 UI.

Bleh. Addendum: part of the process should be an indicator on the phone that means "network service degraded". Half the problem seems to be people being unclear on the fact that the network's being swamped. A visible indication on the phone won't help the deliberately oblivious, but it at least gives those with 2 working brain cells firing in sync a clear indication that yes the carrier knows about the situation, yes they're doing what they can, no you can't expect normal operation right now so just be patient and use SMS when you can.