The company expects me to put in long hours when projects demand it. They expect me to shuffle my lunch around or even skip it completely to get the work done. Well, I need something to eat and drink while I'm working. If I can't conveniently get it in the break room, a quick walk from my desk, then I need my lunch at a reasonably predictable time and I need to be able to go home to eat at a consistent hour. If the company expects work out of me, I expect a certain amount of "perks" from the company in return. If the company doesn't want to help, I'm not going to feel as helpful either. And I'll probably start looking for somewhere else, because once that trend starts of expecting from the developers while not giving a bit in return it inevitably ends in tears. I'd rather they not be mine.
For myself, the reason I don't buy furniture with this feature is that nobody offers it. Period. The problem with wall outlets is that they're all too often behind the furniture where people will be needing the power. So I end up with power bars everywhere, often attached permanently to furniture where power's needed.
You'll notice that in office environments all furniture is equipped for power. There's outlets in the floor, and every desk and counter and a lot of fixed tables have power bars along them or underneath them. My office desks at home have cut-outs for power and provision for attaching power bars. And everybody I know asks one question every time they're looking at a house: "Are the circuits 20A?".
Let me ask this: if nobody needs power outlets, why do power strips and boxes sell so well and why do so many homes have so many of them? Answer: because people need outlets that aren't 2-outlet wall boxes, and few people have the skills and the workshop to actually create furniture equipped for what they want so they cobble together what they need from what they can get.
Your name, address and phone number are published in the phone book. What's sensitive here?
On a Web site, it's done over an encrypted connection not to protect the information but to prevent a third party from sitting in the middle collecting payment information. The combination of personal information with payment information (credit card number and expiration date), that would be sensitive. On their own either set of information should be non-sensitive, but combined it's sufficient to pass the authentication checks merchants and credit-card companies do. But just personal information without any associated payment information, what's anyone going to do with that that they couldn't do by looking through your local phone directory?
And? I delegate cdn.foo.com to the CDN company and let them assign names as they see fit. It's not magic, how do you think the root nameservers delegated foo.com to Foo's nameservers in the first place? C'mon, this is DNS 101, the stuff you were supposed to know before you got your first domain.
Why are managers worrying about meeting some arbitrary criteria set by Google/Microsoft/etc. for a metric that in the end doesn't matter? PUE is irrelevant, what matters to the business is the total cost of providing the computing power the business needs. If you have a cheap way of reducing that cost, take it. But if your cost's within acceptable limits and reducing it further's going to cost too much or take too much resources or investment, then stop wasting your time worrying about it and concentrate on other things you can improve. Like, say, improving the efficiency of your software so you don't need as much computing horsepower and bandwidth to do the job, which will automatically reduce both your power and cooling requirements right there.
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.
Part of it's not just whether the network fails, but how it fails. For instance, in a situation like this the network might be reconfigured to reject incoming calls to the area to keep that capacity free for people calling out. It might start throttling back voice calls to free up that capacity for emergency services and keep the data portion of the network running (and maybe drop the data portion back to 3G or even 2G so it could handle more simultaneous users). You wouldn't be able to call out, but you could still send and receive text messages. And the process for this should be in place. This kind of thing is rare and you can't predict when it'll happen, but it's a given that it will happen so the network operators should have a plan in place for what to do when it does.
And they should also be looking back to Ma Bell's studies on how to staff operators to handle phone calls. They found through a lot of study of real-world traffic that you can't staff for the average volume and successfully handle the calls. Calls tended to cluster, so if you wanted to keep wait times acceptable you had to staff for the peak volumes and accept that that meant you'd have idle capacity a lot of the time. I often get the feeling that the engineering side of the carriers understands this, but the business side doesn't quite grasp the idea of call volume not being a normal distribution.
Check your hiring process. I've run into times when we can't find anyone because all the candidates HR sent us were unsuitable (the ones we interviewed flunked on the basic C/C++ skills test despite claiming a minimum of 5 years experience coding in C/C++), and yet I knew there were at least 2 highly-qualified candidates that HR hadn't sent to us to review because I handed their resumes to HR myself. That right there tells me that the problem might be not that there aren't any candidates but that HR's throwing them out before they ever get looked at. Ditto for recruiters, who probably use the same process HR does to screen candidates.
I've thought it might be amusing to bypass the HR process entirely, task some of the developers with attending the various techie get-togethers around town and collect qualified candidates that way, then give the hiring manager their resumes directly in addition to sending them to HR. Then if their resumes don't show up, the hiring manager can send them up from his side asking "This candidate looks qualified and we'd like to interview them but they weren't in the stack you sent down. I know it should be there, I had one of my devs run it over to you personally. Can you get back to me about what happened to it?".
Which.docx format? The ECMA-376 1st Edition version included in Word 2007, or the ISO/IEC 29500:2008 Transitional included in Word 2010? And what about the formal 29500:2008 Strict format, which the Office OpenXML standard says should be preferred to Transitional but which Word can't write? It makes a difference, since ECMA-376 and 29500:2008 aren't compatible (among other things, date formats differ and dates valid in one format are illegal in the other). I don't know if Office 2013 introduced another variation on the format, I need to remain compatible with work so I can't install Office later than 2010.
Local, remember? If I'm checking in at a place, they don't need to offer coupons to get me in. I'm already going there and know them. If they want to distribute electronically to repeat customers, all they need's a mailing list and a server to send the e-mail through. To attract new business they need to get the offers to the people who live in the area who aren't checking in. Except those people probably already know about the place from driving past it every day, right?
Now, a non-social search site would work, someplace where I can search for businesses in my area with locality-specific information about them. But that's hard because the cost of acquiring that information's high (these are businesses you can't find much out about on-line, to get the info to populate the database you pretty much need actual people wandering around taking notes) and the target audience is small. Hence why Foursquare's having so many problems with generating revenue.
Slashdot Mirror
The company expects me to put in long hours when projects demand it. They expect me to shuffle my lunch around or even skip it completely to get the work done. Well, I need something to eat and drink while I'm working. If I can't conveniently get it in the break room, a quick walk from my desk, then I need my lunch at a reasonably predictable time and I need to be able to go home to eat at a consistent hour. If the company expects work out of me, I expect a certain amount of "perks" from the company in return. If the company doesn't want to help, I'm not going to feel as helpful either. And I'll probably start looking for somewhere else, because once that trend starts of expecting from the developers while not giving a bit in return it inevitably ends in tears. I'd rather they not be mine.
For myself, the reason I don't buy furniture with this feature is that nobody offers it. Period. The problem with wall outlets is that they're all too often behind the furniture where people will be needing the power. So I end up with power bars everywhere, often attached permanently to furniture where power's needed.
You'll notice that in office environments all furniture is equipped for power. There's outlets in the floor, and every desk and counter and a lot of fixed tables have power bars along them or underneath them. My office desks at home have cut-outs for power and provision for attaching power bars. And everybody I know asks one question every time they're looking at a house: "Are the circuits 20A?".
Let me ask this: if nobody needs power outlets, why do power strips and boxes sell so well and why do so many homes have so many of them? Answer: because people need outlets that aren't 2-outlet wall boxes, and few people have the skills and the workshop to actually create furniture equipped for what they want so they cobble together what they need from what they can get.
Your name, address and phone number are published in the phone book. What's sensitive here?
On a Web site, it's done over an encrypted connection not to protect the information but to prevent a third party from sitting in the middle collecting payment information. The combination of personal information with payment information (credit card number and expiration date), that would be sensitive. On their own either set of information should be non-sensitive, but combined it's sufficient to pass the authentication checks merchants and credit-card companies do. But just personal information without any associated payment information, what's anyone going to do with that that they couldn't do by looking through your local phone directory?
And? I delegate cdn.foo.com to the CDN company and let them assign names as they see fit. It's not magic, how do you think the root nameservers delegated foo.com to Foo's nameservers in the first place? C'mon, this is DNS 101, the stuff you were supposed to know before you got your first domain.
Why are managers worrying about meeting some arbitrary criteria set by Google/Microsoft/etc. for a metric that in the end doesn't matter? PUE is irrelevant, what matters to the business is the total cost of providing the computing power the business needs. If you have a cheap way of reducing that cost, take it. But if your cost's within acceptable limits and reducing it further's going to cost too much or take too much resources or investment, then stop wasting your time worrying about it and concentrate on other things you can improve. Like, say, improving the efficiency of your software so you don't need as much computing horsepower and bandwidth to do the job, which will automatically reduce both your power and cooling requirements right there.
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.
Part of it's not just whether the network fails, but how it fails. For instance, in a situation like this the network might be reconfigured to reject incoming calls to the area to keep that capacity free for people calling out. It might start throttling back voice calls to free up that capacity for emergency services and keep the data portion of the network running (and maybe drop the data portion back to 3G or even 2G so it could handle more simultaneous users). You wouldn't be able to call out, but you could still send and receive text messages. And the process for this should be in place. This kind of thing is rare and you can't predict when it'll happen, but it's a given that it will happen so the network operators should have a plan in place for what to do when it does.
And they should also be looking back to Ma Bell's studies on how to staff operators to handle phone calls. They found through a lot of study of real-world traffic that you can't staff for the average volume and successfully handle the calls. Calls tended to cluster, so if you wanted to keep wait times acceptable you had to staff for the peak volumes and accept that that meant you'd have idle capacity a lot of the time. I often get the feeling that the engineering side of the carriers understands this, but the business side doesn't quite grasp the idea of call volume not being a normal distribution.
Check your hiring process. I've run into times when we can't find anyone because all the candidates HR sent us were unsuitable (the ones we interviewed flunked on the basic C/C++ skills test despite claiming a minimum of 5 years experience coding in C/C++), and yet I knew there were at least 2 highly-qualified candidates that HR hadn't sent to us to review because I handed their resumes to HR myself. That right there tells me that the problem might be not that there aren't any candidates but that HR's throwing them out before they ever get looked at. Ditto for recruiters, who probably use the same process HR does to screen candidates.
I've thought it might be amusing to bypass the HR process entirely, task some of the developers with attending the various techie get-togethers around town and collect qualified candidates that way, then give the hiring manager their resumes directly in addition to sending them to HR. Then if their resumes don't show up, the hiring manager can send them up from his side asking "This candidate looks qualified and we'd like to interview them but they weren't in the stack you sent down. I know it should be there, I had one of my devs run it over to you personally. Can you get back to me about what happened to it?".
Which .docx format? The ECMA-376 1st Edition version included in Word 2007, or the ISO/IEC 29500:2008 Transitional included in Word 2010? And what about the formal 29500:2008 Strict format, which the Office OpenXML standard says should be preferred to Transitional but which Word can't write? It makes a difference, since ECMA-376 and 29500:2008 aren't compatible (among other things, date formats differ and dates valid in one format are illegal in the other). I don't know if Office 2013 introduced another variation on the format, I need to remain compatible with work so I can't install Office later than 2010.
Suggestion to MS: just put the Windows 7 UI back on. Oh, and while you're at it, tweak Office to honor the UI theme instead of implementing it's own.
Local, remember? If I'm checking in at a place, they don't need to offer coupons to get me in. I'm already going there and know them. If they want to distribute electronically to repeat customers, all they need's a mailing list and a server to send the e-mail through. To attract new business they need to get the offers to the people who live in the area who aren't checking in. Except those people probably already know about the place from driving past it every day, right?
Now, a non-social search site would work, someplace where I can search for businesses in my area with locality-specific information about them. But that's hard because the cost of acquiring that information's high (these are businesses you can't find much out about on-line, to get the info to populate the database you pretty much need actual people wandering around taking notes) and the target audience is small. Hence why Foursquare's having so many problems with generating revenue.