Microsoft Builds New Tool To Help Gmail Users Move To Outlook.com
Microsoft
would greatly appreciate it if you could knock off that Gmailing
business and move to its Outlook.com email service. I refuse to, and so
do more people than Microsoft prefers, so the company today released a
new tool that will make it easier for Gmail users to jump ship.The Outlook.com switching tool is designed to make changing inbox homes more seamless and less an exercise in re-tagging. It will propagate over the next few weeks to all 400 million-plus Outlook.com users — as well as current Gmail users who have yet to make the move — a simple path to a new email home.
The tool, which you can find directions for here, will hold your hand when changing teams, though expect to wait a bit as it could be a while for your email to slip over. The transition will bring over your most recent email more quickly than the rest. But, you should be sorted in short order. The new tool will land over the next few weeks. If you don’t have it now, sit tight.
The company has research indicating that people are more willing to change email providers if the friction betwixt the two is minimized. That’s logical. So, as Microsoft wants to knock Gmail off its tech throne (name a technology leader who swears by Outlook.com over Gmail), it is working to lower the delta between leaving Google and dropping into its own product.
Outlook.com is a worthy tool that is far superior to its Hotmail predecessor. Buckled with functionally unlimited storage, Outlook.com grew quickly organically, and then benefited from the end of Hotmail itself.
Technology Lab / Information Technology
Is it a good or bad idea to rotate developers on a single project?
This Q&A is part of a weekly series
of posts highlighting common questions encountered by technophiles and
answered by users at Stack Exchange, a free, community-powered network of 100+
I'm part of a small team that will begin working on a large new
project with another small team. The other team is currently working on a
legacy system that they have been working on for years.The manager has decided that the developers from my team will be rotating every few months to replace developers working on the legacy system. That way the other team will have a chance to work on the new project and have a better understanding of the new system.
I want to know the benefits and drawbacks (if any) of rotating the developers from the project every 2-3 months.
I know that this is a similar question to "Is rotating the lead developer a good or bad idea?" but that question focuses on a lead developer. This question is about rotating the entire team on and off the project (our tech lead for the new project may or may not be rotated—I don't know yet).
See the original question .
Sounds great
I don't see much of a downside here myself. The rotation gets you:Cross pollination of institutional knowledge: everyone will know the legacy project and the new one, at least in theory.
Cross training: different projects require different things often. You grow much more as a developer working in ugly legacy projects than in nice, clean greenfield projects.
Fundamentally better projects: nothing like having a new team coming in to make you finish documentation and clean up ugly processes you are willing to live with but not publicly admit to.
Better code: more heads are better in most cases.
Likely morale improvements: variety is the spice of life. And who wants to be stuck in legacy project bug fixing/duct-taping mode permanently? Also keep in mind your "new" project will become legacy at some point: do you want to be stuck there forever?
Probably the only downside is the productivity drop you get from switching places but that should only hurt bad the first go-round. Afterwards, both sides will have some seat time in both places and the ugly parts of the handoff will probably be better understood and perhaps solved.
Sounds not-so-great
I'm surprised that everybody thinks this is such a good thing. The authors of Peopleware (which, in my opinion, is still one of the precious few software project management books actually worth reading) strongly disagree. Almost the entire Part IV of the book is dedicated to this very issue.
The software team is an incredibly important functional unit. Teams need to jell to become really productive. It takes time (a lot of time) for team members to earn each others' respect, to learn each others' habits and quirks and strengths and weaknesses.Certainly, from personal experience, I can say that after a year of working with certain people, I've learned to laugh off certain things that used to rile me up, my estimates as team lead are much better, and it's not too difficult to get the work distributed so as to make everyone happy. It wasn't like that in the beginning.
Now you might say, "Oh, but we're not breaking up the whole team, just moving a few people." But consider (a) how blindly unproductive their replacements are going to be in the beginning, and (b) how many times you'll find yourself or other teams saying, without even thinking, "I really liked X," or "This would have been easier with Y still around," subtly and unconsciously offending the new members and creating schisms within the existing team, even sowing discontent among the "old" members.
People don't do this on purpose, of course, but it happens almost every time. People do it without thinking. And if they force themselves not to, they end up focusing on the issue even more and become frustrated by the forced silence. Teams and even sub-teams will develop synergies that get lost when you screw around with the structure. The Peopleware authors call it a form of "teamicide."
That being said, even though rotating team members is a horrible practice, rotating teams themselves is perfectly fine. Although well-run software companies should have some concept of product ownership, it's not nearly as disruptive to a team to move that entire team to a different project, as long as the team actually gets to finish the old project or at least bring it to a level they're happy with.
By having "team" stints instead of "developer" stints, you get all the same benefits you would expect to get with rotating developers (documentation, "cross-pollination," etc.) without any of the nasty side-effects on each team as a unit. To those who don't really understand management, it may seem less productive, but rest assured that the productivity lost by splitting up the team totally dwarfs the productivity lost by moving that team to a different project.
P.S. In your footnote you mention that the tech lead might be the only person not to be rotated. This is pretty much guaranteed to mess up both teams. The tech lead is a leader, not a manager, he or she has to earn the respect of the team and is not simply granted authority by higher levels of management. Putting an entire team under the direction of a new lead whom they've never worked with and who is very likely to have different ideas about things like architecture, usability, code organization, estimation... well, it's going to be stressful as hell for the lead trying to build credibility and very unproductive for the team members who start to lose cohesion in the absence of their old lead. Sometimes companies have to do this, i.e. if the lead quits or gets promoted, but doing it by choice sounds insane.
Ministry of Innovation / Business of Technology
The Christmas miracle of ChristmasCats.tv
The mystery webcam is gone, but the story of the Internet sensation remains.
The elf imbibes from a flask while granny knits with her cats to the crooners of old-timey Christmas music.
It looked for all the world like a public access channel holding pattern, with only a couple more accoutrements than the looping video of a fireplace set to holiday carols. It combined that comforting, if artificial, display with one of the Internet’s greatest gifts: animal cams. Not only was the set replete with cats, but with people to play with them. They were also available for adoption (the cats, not the people).
The entire setup was actually in service of selling the old Christmas music playing as the background to the cats’ antics. Sony’s digital marketing department created the setup as a vector for the company’s classic Christmas album catalog. This motivation wasn't even betrayed by the “buy now” link, which linked only an online search for “classic christmas albums.”
The marketing team was tasked with “[imagining] a holiday campaign for legacy recordings,” said Jason Cohen, senior director of digital marketing. Cohen described himself as an owner of four cats and said he happened to note that cats are somewhat of interest to the Internet. “It’s kind of a challenge to work with an Internet meme,” he admitted.

Cohen and his team hired the two actors (the grandmother is actually a grandmother, Cohen said) and penned them in on a stage in Greenpoint, Brooklyn with a handful of cats from the North Shore Animal League (NSAL). All of the cats were available for adoption.
Cohen told Ars that the stage only operated from 9-5 for the three days ChristmasCats.tv was live. The area fenced in with plywood for the cats to roam was actually twice as large as what the camera showed, with room for the cat’s litterboxes, food, and water at the foot of the camera.
The NSAL received many requests for their cats and “loved” the campaign, Cohen said.
The ChristmasCats.tv Twitter account started with no followers just before launch, and the Facebook fan page started with no likes. They ended with 1,180 followers and 2,869 likes—a modest success, but enough that Sony would consider a similar campaign again, Cohen said. “It was about the music and helping the cats,” Cohen said. “I think we did a good job.” The original live footage is now playing on a loop, which Cohen says will likely stay up through Christmas.
No comments:
Post a Comment