June 29, 2013 § Leave a comment
A Google Gaming Console? It’s Madness!
Bubbling up in today’s news stream is a report thatGoogle wants to get into the game console businessand that Apple may too.
In a column earlier this week I concluded that unless a big spender willing to throw money away comes along, nothing will change. It’s a duopoly. That is, unless you think the business can be sustained by the Angry Birds franchise.
Let’s dissect some of these developments. To begin, the Google threat is a rumor. If it becomes more than a rumor it will become a pipe dream.
Both Google and Apple should be doing the logical thing: turn the tablet into a game machine. The idea is to sell tablets. What is the point of adding a game console unless it is nothing more than an HDTV interface?
The Nintendo Wii U comes with a small, dedicated tablet on which you can actually play a game without a TV or screen. I’m sure this attracted the attention of the folks at Google and Apple.
But instead of copying Nintendo while competing with Xbox and PlayStation, both Apple and Google should be sponsoring some development work designed to create a killer tablet-based game. This is where the future lies, not in clunky game consoles that many people only use for Netflix.
Also, does anyone think that Google and Apple are serious? Are these companies sincere or are they just scrambling for something to make it look as if they are growth companies?
I hope that none of this is true. The console side of the tech industry is a zombie. It’s not as if I don’t expect to see Halo 12 and Call of Duty 14 years from now, but how drab can the future be if you are looking at a screen carrying a virtual gun and roaming around some battlefield waiting for some action? If the economy ever corrects, nobody is going to have time for any of this. And if they do, then it’ll be on a tablet.
If Google or Apple indeed brings out a gaming console, I’ll be stunned. But if they create some sort of tablet add-on that has the controls similar to the Nintendo Wii U, which then hooks up to a tablet, then I’d say fine, at least this sort of retro idea sells more tablets. If instead neither company plans on doing anything and this is all part of a scheme to harass Microsoft, then great. But an actual game console based on iOS and Android? It’s madness.
June 27, 2013 § Leave a comment
Martin Fowler at GOTO Amsterdam 2013 about Agile Essence and Fluency
by Ben Linders
The second day of the GOTO Amsterdam 2013 conference stared with a keynote by Martin Fowler on software development in the 21st century. He explored the reasons why agile was started in the 90s to discuss how teams can become fluent in agile, and reach for the stars.
Agile started as an answer on projects that were late, delivering buggy software to unhappy users, and had developers that were demotivated by this. Plan driven methods were used at that time to develop software, and Martin compared them to agile. Agile differs as it uses adaptive planning where plan driven uses predictive planning. Where agile focuses on the people, plan driven methods are mostly about processes. In plan driven methods there are separated steps to plan your work, and work your plan, and success is defined as “according to plan”. Since the plans depended on requirements stability, plan driven methods wanted to stabilize requirements, where agile wants to break the dependency between plans and stable requirements by embracing change.
As Martin mentioned earlier, agile also differs with plan driven on how it views processes and people. He showed how agile has a shift in mindset to “people first” in stead of “processes first”. Software development processes in plan driven methods are viewed as consisting of steps and links between steps, involving people who will follow the process. Agile takes a different approach, by starting with assembling good people into a team, and then let the team decides on a suitable process. Martin stated that it is “wrong to command a team to become agile”. Team will chose themselves to do things agile or not, and that’s ok.
This brings up the question when teams should agile, and when not, and how fluent they want to be in agile. Diana Larsen and James Shore wrote about Agile Fluency, and Martin published their article in your path through agile fluency. Diana and James defined fluency as:
Fluency is how a team develops software when it’s under pressure. Anyone can follow a set of practices when given time to focus in a classroom; true fluency is a skillful, routine practice that persists when your mind is distracted with other things.
Martin presented how teams can increase their agile fluency, from a first star level up to four stars. At the first star level, teams divide the work up in individual chunks to deliver business value. You need to invest in team development and process design to reach this level, it typically takes 2-6 months for a team to reach it. Teams at the two star level “ship on the market cadence”; realizing more value by delivering as often as their markets can handle. An investment is needed in technical skills and practices like XP, TDD and pair programming to increase software craftsmanship and get a productive team which delivers software with less defects. It typically takes teams 3-24 months to get on this level.
Teams on the third star level are optimizing their business value using metrics, and teams on the fourth star also contribute to enterprise wide success. Martin mentioned that he doesn’t see many teams on star level three and four. He suggest for teams to think about which level that they would want to reach, and if they are able and willing to do the investment.
November 22, 2012 § Leave a comment
Pair programming can be tough for even the best developers. It can be downright daunting if you haven’t done it before, are introverted or unsure of yourself. For those of you who want to improve your pair programming abilities, the following seven secrets are helpful strategies in accomplishing that objective. They are distilled from my 10 years experience pairing as a developer, technical lead, test driven development mentor and Agile coach.
Pair Programming Secret #1. Proficiency
Proficiency with the language and proficiency with the IDE are paramount to working as an effective pair partner. When you program with a pair partner you have nowhere to hide. All of your skills and abilities, along with your fears and shortcomings, will be on display for the team to see. To overcome these challenges, you must first accept that there will always be someone out there who knows more than you do.
Secondly, you should work to improve yourself in the places where you feel weak or unsure. Try spending 30 to 60 minutes per day, for a couple of weeks, on self-improvement in the areas you are worried about. You’ll be surprised by the results.
Finally, you must master your IDE. Almost all modern IDEs have a wide range of shortcut keys for the most commonly used actions and commands. Find a reference card for your IDE on the Internet and highlight the ones you think will be most useful to you. Then memorize the shortcuts and start using them every day. Your pair partner will appreciate your mastery of the IDE and you will improve your efficiency.
Pair Programming Secret #2. Communication
In any relationship, communication is key. Pairing is a very intense, albeit short relationship between two people working collaboratively towards a shared goal. Before you dive in to writing code, spend a few minutes discussing the task and identifying an approach to implement a solution. Doing so will ensure that you and your pair partner agree on what to do and how to do it.
When it’s your turn at the keyboard, keep your pair partner informed. You need to verbalize your thought process to let your pair partner know where you are heading and why. Try to articulate what you are doing and ask your pair partner questions to help keep him or her involved and engaged. For instance, after passing a test, I will often say, “What do you think?” and offer the keyboard. This is a chance for my pair partner to improve, refactor or write another failing test.
Pair Programming Secret #3. Self Confidence
When you are confident in yourself and your abilities, you feel comfortable offering and receiving constructive criticism. Self awareness of your strengths and weaknesses, coupled with a confidence that you “can do this” allows you to relax and focus on your work rather than on your shortcomings. Additionally, you will be able to open yourself up to constructive criticism and you will have the perspective necessary to determine if the criticism is relevant and actionable.
With self confidence, you will find that you are more willingly to ask questions and try out new ideas. Your self confidence can inspire better communication on the team by setting the example that you are willing to admit that you don’t know everything and are willing to ask for and accept help. When you’re self confident you don’t worry about what others are thinking about you or about your productivity, so you are more willing to take chances and try innovative solutions.
Pair Programming Secret #4. Self Control
The discipline of software development requires a significant amount of mental effort and focus. It’s easy to have self-control lapses when we are bored, tired or frustrated. Anything that distracts your attention can be a potential productivity killer.
The high-functioning teams that I have witnessed leverage their “team norms” or “ground rules” to help reduce the number of potential distractions. You can also leverage good Agile principles to stay focused. Use spikes to investigate new ideas and techniques. Add a “time allowance” to your spike story to keep from going down an endless “rabbit hole.” These are key because when you’re working on an Agile team you’re responsible not just for yourself, but for everyone else on the team. That’s what we mean by the “whole team approach.”
If you’re having trouble focusing, you should be able to rely on your pair partner and your team to help get you back on task. Just the same, if you notice that someone else is having a hard time staying focused, you need to be willing to step up and help them get back on track. Remember, you will succeed or fail as a team.
Pair Programming Secret #5. Patience
We have clearly established that writing code with a pair partner is very different from hacking alone all day. Your patience, or lack thereof, doesn’t usually affect others when you’re working alone. If you’ve spent your whole career as a solo “keyboard jockey,” pair programming will put your patience to the test.
As a pair partner you won’t always have control of the keyboard and mouse, and it is considered bad form to rip the mouse out of your partner’s hands. So when you get the urge to grab, take a deep breath, exercise your self control, and then use your best manners to ask, “May I?”
Once you get control of the keyboard and mouse, you should be willing to relinquish it without a fight. Liberal keyboard passing helps keep both pair partners engaged and motivated. Some of the best athletes in team sports are the ones willing to sacrifice a small personal victory and make a pass to a teammate in order to achieve a larger team “goal.”
Manners in the workplace seem to have gone the way of chivalry, yet good etiquette is a crucial part of human interaction. Programmers often forget this because they don’t have to thank their shell script for searching through a log file, nor do they have to ask their laptop to politely launch their favorite IDE. However, when pairing, good manners are expected and poor manners are not easily forgiven.
I find it useful to start off a new pairing session by setting a few simple ground rules. If you prefer to formalize these ground rules you can work with your team to create a set of team ground rules for pairing. Whichever way you go, just remember that it is necessary to have a shared understanding of how you will work together as a pair before starting, to avoid confusion and hurt feelings. You might be surprised to learn the actions that distract or bother your co-workers.
By working to improve your manners I think you will find that you will have more enjoyable pairing sessions and will become one of the most sought after people to pair with on the team.
Pair Programming Secret #7. Hygiene
This should really go without saying. Unfortunately, I have to say it because too many people ignore the use of basic hygiene in the office. It’s better that you hear it in the context of an article than suffer the embarrassment that poor hygiene could cause later. So consider this a quick “Health Class for Pair Programmers.”
Of course, you should shower every morning, brush your teeth and use deodorant. Throughout the day you need to be mindful of your breath and consider brushing, following up snacks and meals with a mint or breath freshening gum. If you smoke, you should always wash your hands and freshen your breath before returning to your workspace. If you cough or sneeze, be sure to cover your mouth using the inside of your elbow as a shield and sound muffler. Always keep hand sanitizer nearby to keep your hands clean and sanitary throughout the day.
In addition, if you work in a bullpen or Agile room, it’s important to remember to clean up after yourself. It’s not fair to the pair that will come behind you to have to clean up before they can start working.
Toward Pair Programming Perfection
Hopefully, you will find these seven secrets helpful for your next pairing session. I have probably violated every principle of every secret in this article and this is part of what has made it possible for me to compile these secrets. But thanks to my years of experience and with help from my teammates and coaches, I have gained a level of self awareness that now allows me to make the necessary adjustments to become a more effective pair programmer in the workplace.
By no means have I completed this journey, but I am a better pair programmer today than I was yesterday. It is for this reason that I define success, not as the attainment of a static goal, but rather as the continual attainment of small goals on a path toward perfection, and with the full awareness that my journey as a pair programmer will end well before achieving perfection.
Did I leave out any important traits for successful pair programming? If so, tell me about them in the comments below.
November 14, 2012 § Leave a comment
Interesting article I read posted by Bradley Jones… That I want to share and put in my blog
As you can see, bugs and defects in software can be extremely costly to an organization — to the level of $60 Billion (US) dollars a year. That’s about $113,333 a minute. Fixing bugs earlier is obviously cheaper. Take a look at the infographic. It has a lot of interesting statistics including the stat that agile projects are 300% more likely to succeed thank non-agile projects. Ironically, the statistics don’t show how much more likely an agile project is to have a bug…!
October 24, 2012 § Leave a comment
(Posted by Glassdoor Team)
It pays to be a software engineer these days, literally.
However, a talented software engineer can be tough to find and many companies are investing big bucks for the best talent. But how big are we talking, and how does software engineer pay compare across companies and location?
Glassdoor, the leading social jobs and career community, turns to salary reports shared over the past 12 months by software engineers at 15 various tech companies to reveal how their average base salary compares*.
Here’s the breakdown:
Pay by Company
Of the 15 tech companies in this report, Google Software Engineers earn the highest average base salary for 2012 ($128,336). Trailing closely behind are software engineers at Facebook ($123,626), Apple ($114,413), eBay ($108,809) and Zynga ($105,568).
Interestingly, Google continues to pay its software engineers more than Facebook, though Facebook may be closing the gap. In 2012, Facebook software engineers earned an average base salary of $128,336, while those at Facebook earned $123,626. In 2011, Google software engineers earned an average of $114,596, while those at Facebook earned $107,744.
In addition, the 2012 national average for a software engineer’s base salary is $92,648, based on more than 5,000 salary reports, an increase of 2.5% compared to the year prior. Software engineers at 13 of the 15 companies on this report enjoy an average base salary higher than the national average of $92,648. However, Intel ($92,194) and IBM ($89,390) software engineer base pay comes in slightly below the national average.
Pay by Location
When we take a look at 15 of the largest U.S. metros in 2012, the San Francisco Bay Area (CA) leads the way for software engineer average base salary ($107,798), followed by Seattle, WA ($102,006), San Diego, CA ($93,529), Boston, MA ($93,403), and New York, NY ($92,701). Software engineers in Minneapolis, MN earn the lowest among the list of regions ($75,032).
In 2011, the San Francisco Bay Area also led the way in terms of average software engineer base pay ($105,120). From 2011 to 2012, the San Francisco Bay Area’s average software engineer base salary increased 2.5% – on par with the 2.5% national average increase from 2011 to 2012.
Curious to know what software engineers at these tech companies have to say about their compensation? Check out some of the recent employee commentary shared by software engineers:
“Everybody who’s paying attention knows how great the perks are. Between on-site gyms, massage, a wide selection of health benefits, 401k and stock grants, competitive salary, and of course the free, gourmet meals, it’s one of the cushiest jobs in Silicon Valley.” – Google Software Engineer II (Mountain View, CA)
“Amazing perks, job opportunities, co-workers, and compensation (in the tech industry). Extremely high levels of autonomy and work flexibility.” – Facebook Software Engineer (Menlo Park, CA)
“Awesome perks, pay and bonuses (STOCKS). Good growth perspectives for engineering and engineering management roles. Amazing job security.” – Apple Software Engineer (Cupertino, CA)
“Good salary and benefits. If you work hard and flaunt your accomplishments, making your boss look good, you can get recognized. They are trying hard to foster employee retention and growth, so you’re encouraged to develop your skills through classes outside of work.” – eBay Senior Software Engineer (San Jose, CA)
“Great package (salary, bonus, stock). Cool cutting edge tech. Great benefits (delicious food, party, massage).” – Zynga Software Engineer (San Francisco, CA)
Are you a software engineer? How does your base salary compare? Share a salary report.
*Based on at least approximately 20 software engineer salary reports per company for 2012 (10/8/11-10/7/12) and 2011 (10/8/10-10/7/11).
September 19, 2012 § 4 Comments
That’s the initial idea of the PhoneSat project, a small satellite project run by a team of engineers at NASA’s Ames Research Center. The PhoneSat team has built and developed two small satellite models powered by Android smartphones, with the rest of the body constructed mostly of things you could buy at your nearest hardware store.
At a 2009 meeting of the International Space University’s Space Studies Program, a group of young engineering students had a big idea: Why not try to develop a cheap satellite-control system using mostly off-the-shelf consumer technology items? They wanted to see if they could create something that could survive in space using existing technology, rather than spending resources to invest in building items from the ground up.
The idea is relatively simple. “Here’s what you have in your pocket, and it can fly in space,” says Oriol Tintore, a software and mechanical engineer for NASA’s PhoneSat project.
After we reported on these microsatellites earlier this summer, the PhoneSat team invited us to visit their lab at NASA’s Ames Research center in Moffett Field, California, in the heart of Silicon Valley. They showed off the two current PhoneSat models, PhoneSat 1.0 and PhoneSat 2.0, and further explained their upcoming mission, now scheduled for November 11, 2012.
PhoneSat: Meet the team, and the units
At a 2009 meeting of the International Space University’s Space Studies Program, a group of young engineering students had a big idea: Why not try to develop a cheap satellite-control system using mostly off-the-shelf consumer technology items? They wanted to see if they could create something that could survive in space using existing technology, rather than spending resources to invest in building items from the ground up. This big idea put the PhoneSat project into motion.
Today, team PhoneSat is a small group of about ten engineers, led by Small Spacecraft Technology program manager Bruce Yost and PhoneSat project manager Jim Cockrell.
“[PhoneSat] gives young engineers a chance to work on something that’s actually going to fly in space early on in their careers,” said Cockrell.
Although the project idea emerged in 2009, the building, designing, and testing of the parts that would make up the PhoneSat 1.0 model began in 2010. To power the satellite units, the PhoneSat team turned to small phones with large processors.
“This phone has a very powerful processor of 2.4MHz, which is more powerful than most processors out there in space,” says Jasper Wolfe, who handles altitude control for the project. “It has just about everything we need, so why not use it? It’s a few hundred dollars compared to tens of thousands of dollars.”
The units themselves are small—compact enough to fit in your hand. At 10cm by 10cm by 10cm, each device is barely larger than a coffee cup. And the cost of each of these units is relatively cheap: PhoneSat 1.0 costs roughly $3500, while PhoneSat 2.0 is about $7800 due to its more advanced hardware.
PhoneSat 1.0 houses a Google Nexus One smartphone, which runs a single Android application that the team developed themselves. All of the Nexus’s phone capabilities have been disabled—Wolfe jokes that they have to set the phones to “airplane mode” before launch—and instead the device relies on the PhoneSat app for communication and data recording.
The PhoneSat team was initially attracted to the Nexus One because, at the time, it was one of the best smartphones available. Plus, they liked the open-source nature of developing for the Android platform.
“We talked about whether we should use an Android phone versus something else, like an iPhone, and the consensus was that the iPhone was a great phone, but an Android phone was a great satellite,” says Tintore, the team’s mechanical and software engineer.
Besides the Nexus One, the main pieces of the satellite include external batteries and an external radio beacon. A watchdog circuit will monitor the system and reboot the Nexus if necessary.
The team plans to evolve the satellites as technology evolves, which is why PhoneSat 2.0 uses a Samsung Nexus S instead of a Nexus One. In fact, the Nexus S has an added gyroscope already built in, which has been “extraordinarily helpful” in building a next-gen satellite, according to Wolfe. “It’s just a tiny little chip, but very useful,” he says. The gyroscope helps the phone measure and maintain orientation, so it assists with navigation as well as with the motion and rotation of the phone itself.
PhoneSat 2.0’s design includes a two-way S-band radio, solar arrays for unlimited battery regeneration (“Well, for as long as there is sun,” says Yost), and a GPS receiver. The radio will command the satellite from the ground, while the solar panels will enable the unit to embark on a mission with a long duration. Also built into the PhoneSat 2.0 design are magnetorquer coils (electromagnets that interact with Earth’s magnetic field) and reaction wheels to control the unit’s orientation in space.
Each model has been tested in environments that closely resemble what they could encounter while in space. Two Nexus One phones were launched on smaller rockets in 2010 as a preliminary test of how the phones will handle high speeds and high altitude. One rocket crashed and destroyed the smartphone; the other landed with the Nexus One perfectly intact. Both PhoneSat 1.0 and 2.0 models have also been tested in a thermal-vacuum chamber, on vibration and shock tables, and on high-altitude balloons, all with great success.
PhoneSat’s first mission: survival
Three of the PhoneSat units—two PhoneSat 1.0 models and one PhoneSat 2.0—are gearing up for their first mission. They’ll be hitching a ride on the first test flight of the orbital Antares rocket, which is scheduled to launch on November 11. Because the satellites are “hitchhikers,” according to the team, their status is entirely dependent upon when the Antares is ready to fly. The Antares’s first test flight was originally supposed to occur in August of this year, but that was delayed due to complications with the launch facility.
The delay of the launch was somewhat beneficial to the PhoneSat team, because it gave them more time to improve PhoneSat 1.0 and test PhoneSat 2.0. Originally, only PhoneSat 1.0 models were scheduled to fly on the Antares, but the delay allowed for a PhoneSat 2.0 model to go for a ride as well.
Each PhoneSat unit has its own role in the mission, which is more of a tech demonstration to show off what the team has accomplished with these microsatellites. The team jokes that PhoneSat 1.0 has a simple Sputnik-like goal of broadcasting status data back to Earth and taking photos. PhoneSat 2.0 will test the subsystems on the satellites themselves—features such as desaturation, location control, and the power-regeneration system.
The satellites will be in orbit for about 10 to 14 days before they reenter our atmosphere. According to Cockrell, mission duration isn’t limited by battery life and power, bur rather by atmospheric drag: The higher the satellites go, the longer they will stay in orbit. Although the PhoneSat 1.0’s batteries are expected to run out after ten days, PhoneSat 2.0 is solar powered, so it could, in theory, live longer. But it will still come back at around the same time as the two PhoneSat 1.0 models will, because they all have roughly the same mass.
The future of PhoneSat
The team has plenty of ideas on things they’d like to try in the next PhoneSat rebuilds. Because their projects aren’t specific missions and are more about tech demonstrations, the team can always develop further by adding new subsystems. They definitely envision building a PhoneSat 3.0, a 4.0, and even more, because the team views the project as never being fully complete.
“We don’t have a defined level of when it’s completed,” Wolfe explains. “[It’s more about] however much you can make in a bit of time, how much can you get out of three months, then six months, and so on.”
According to Alberto Guillen Salas, the team’s hardware engineer, using materials that are mostly already built and ready to go gives the team the ability to develop satellites in a very short time. That way, they can test the units often to keep improving them.
As for smartphone models to try next, Wolfe suggested the Samsung Nexus Galaxy “because of the name” and to stick with using phones from the Google family. The team would also like to use a smartphone with a high-resolution camera to capture good quality photos from space.
PhoneSat’s next expected launch will be in the summer of 2013, when the team will be advancing the development of the PhoneSat 2.0 unit. The primary focus of this next tech demo is to push the 2.0 system and see what the group can do with it. Plus, the team can use information gathered from the first PhoneSat 2.0 launch this year to make improvements on the model. Radiation testing is extremely difficult to perform, so Cockrell anticipates that the team may have to update PhoneSat 2.0’s design to protect it from radiation for future launches. Only one unit will participate in the 2013 launch.
The part of the PhoneSat project that really excites the team is the possibility of involving the public in future PhoneSat developments, mainly through Android application development. The group would like to open the project up to allow people to write apps for the PhoneSats, and then send the units into space. The PhoneSat project has gathered interest through its public appearance at Maker Faire, through Random Hacks of Kindness, and through the International Space Apps Challenge.
“We’re getting a whole new crowd of people involved in space, people that didn’t have the money to get involved before,” says Wolfe, “though the leveraging of the open-source community around Android is also opening up a whole new market of people who want to get involved in space.”
(Source : http://www.techhive.com)
September 19, 2012 § 2 Comments
The Xbox, the Zune, Windows Phone: in ten years, these products will be the model for Microsoft, as it evolves away from a software company into a hardware-and-services provider. At least, that’s the corporate vision outlined by Microsoft CEO Steve Ballmer this weekend.
Ballmer formalized the shift in strategy in an interview published by the Seattle Times over the weekend. Among other topics, Ballmer talked about the blurring lines between tablets and PCs – and dropped hints about the price of the company’s upcoming Surface tablets.
An Epic Year For Microsoft?
Microsoft is updating all of its major product lines this year, with the new Windows 8, Office, Windows Server and Internet Explorer releases, plus ongoing updates to the software used by its Xbox gaming platform. But while Ballmer called the year “epic,” he appears ready to if not jettison those products, at least subsume them in a new wave of devices around which Microsoft can develop platforms.
“I think when you look forward, our core capability will be software, [but] you’ll probably think of us more as a devices-and-services company,” Ballmer told the Times. “Which is a little different. Software powers devices and software powers these cloud services, but it’s a different form of delivery….
“Doesn’t mean we have to make every device,” Ballmer added. “I don’t want you to leap to that conclusion. We’ll have partners who make devices with our software in it and our services built in… We’re going to be a leader at that.”
Surface Pricing Secrets?
The latest example of Microsoft’s newfound love of devices is the Surface tablet, which will be designed by Microsoft in both the Surface RT and Surface Pro configurations; the basic model will use the Windows RT operating system and an ARM chip, while the more powerful model will use a traditional x86 Intel chip and the new Windows 8 OS.
One of the most important unanswered Surface questions has been what Microsoft plans to charge for the devices; analysts have said they believed that Microsoft would be justified in charging a premium, perhaps up to $1,000 for the higher-end surface configuration.
But Ballmer’s interview might have given away a little more of his thinking on the subject. Ballmer was asked whether or not the Surface would compete with the Apple iPad on price or on features. Ballmer didn’t reply directly, but framed his answer by noting that cheaper devices are often expected to be less full-featured.
“If you say to somebody, would you use one of the 7-inch tablets, would somebody ever use a Kindle (Kindle Fire, $199) to do their homework?” Ballmer answered. “The answer is no; you never would. It’s just not a good enough product. It doesn’t mean you might not read a book on it…
“If you look at the bulk of the PC market, it would run between, say, probably $300 to about $700 or $800,” Ballmer said. “That’s the sweet spot.”
So will a Surface RT be priced about $300, with the higher-end models running between $700 to $800? Sure sounds like it.
Microsoft Moving “Away” From Software?
It’s a real stretch to imagine Microsoft ditching its cash cows: Windows, Office and its enterprise products like Windows Server, SharePoint and related services. After all, those produts make up the bulk of the company’s revenues.
But a transition to a cloud-based services model does make sense. Today, Microsoft delivers more than 200 online services to more than 1 billion customers and 20 million businesses in more than 76 markets worldwide, the company recently claimed.
Of course, the majority of these are delivered by the original computing “device,” the PC. But as rivals like Google capitalize on their own services and advertising-driven models, Microsoft has to take additional steps in this direction. While the new Microsoft Office Web Apps make a conscious effort to avoid giving away Microsoft Office’s value-added features for free, they clearly pave the way toward a services-driven future.
Xbox And Beyond
In devices, Microsoft manufactures the Xbox, its own platform for online movies and music sales. And though it has done so quietly, Microsoft also sells its “own” PCs: the “Signature” line of notebooks that it buys from its OEM partners, optimizes by removing adware, and sells directly to consumers.
Ballmer took pains to avoid stating that Microsoft would in fact, make every device that uses its software. But his statement offers ammunition to those who think that Microsoft may end up buying Nokia, its premier Windows Phone partner which just happens to have an ex-Microsoft exec, Stephen Elop, as CEO. Microsoft’s “Signature” strategy could eventually morph into a Google Nexus-like approach of building a “flagship” notebook that hardware partners could use as a reference model.
Windows 8 Is All About Mobile
Ballmer also offered one more telling tidbit: “[Windows 8] also brings us into this world of much more mobile computing and more mobile form factors,” Ballmer said. “I think it’s going to be hard to tell what’s a tablet and what is a PC.
Microsoft’s decision to enter the tablet hardware market has already proved problematic for at least one notebook manufacturer, Acer, which has publicly complained about Microsoft’s decision to manufacture the Surface tablet. But Ballmer’s statement can also be read another way: that making traditional notebooks is a backward looking strategy, and those companies who cling stubbornly to their old business models may be passed by.