Android and The Art of War
Android and The Art of War
Join the DZone community and get the full member experience.Join For Free
I can’t help but feel that Google employed some Art of War when they decided to take on Microsoft by making a mobile platform. That’s with Android of course.
If ‘search’ generally, and ‘ads’ as a consequence (and it’s revenue) were targeted by Microsoft in 2005, then Google needed to preemptively attack Microsoft to protect them. Microsoft would go on to buy PowerSet in 2008, and were probably shopping around before in 2005. Search was definitely under threat.
Read the chapter summary of Sun Tzu’s Art of War, then come back here. I’m not going to attempt to match aspects of Google’s plan to individual chapters of Art of War. I’m just going to do a rollup instead with aspects around weakness, confrontations, focusing resources and diverting your opponent’s, tactics, timing and maneuvers.
People & Process
Google perhaps knew they had more efficient development practices, tuned towards throughput and earliest feedback (including embracing change). They had ex-Microsoft people on board, and understood the differences in their respective “ways” quite well. Google calculated, in terms of resources, they could win for their stated goal – to launch a relevant and compelling mobile OS. They knew also that they would cause Microsoft to divert resources and executive attention to defend the mobile technologies it was promoting. The diverting of resources would help towards their unstated goal – protecting Ad revenue.
In terms of Technologies, Google had huge adeptness with Java. While we all might agree with the fact that Microsoft’s C# is a better language than Java, the libraries and wider eco-system is not so universally agreed. Microsoft’s tools and frameworks are typically much bigger installs and are not so fast moving (compare Visual Studio to IntelliJ IDEA). Sun had the cut-down J2ME environment and would not lift their gaze to J2SE, despite proofs of concept for mobile on Arm as early as 2002, so it was time for Google to take over Java on mobile.
Anyway, back in 2005, MS were schizophrenic about .Net. There were not sure whether to go further into the “write an OS in C#” or retreat from it. That was not just for mobile, that was for desktop too. This is relevant because of the ‘timing’ aspect of Art of War.
Internally to MS, it was suggested that there is an amount of repetition and redundancy in terms of implementation. This is more obvious with the likes of the office suites, but Google perhaps knew their culture/obsession of/with reuse was more healthy. Perhaps that is a people/process aspect again.
Worth calling out is Google’s Source-Control usage versus Microsoft’s. As mentioned yesterday, Google do trunk based development. At the outset of Android, they knew how they’d hive off a team and do high-throughput development work. Microsoft were probably still using “Source Depot” internally at that time, although teams were beginning to plan for a flip to TFS. TFS was inspired by Source Depot (which was a one-time shipment of Perforce for MS). TFS, back then, was not as good as it is now (and many will argue that it is still not good).
In 2005, Google knew their opponent was temporarily weak because of all that I mentioned.
Windows CE = blue, Pocket PC = red/orange, Windows Mobile = gold.
The reality of what they have achieved is perhaps beyond their expectations:
Android = purple, Windows Phone = green
I can only guess at the maths needed to work out the break-even point of taking Googlers out of regular development, and putting them on to Android development with a deferred “revenue protection” aspect for Ads. Here are some Wolfram-Alpha figures for per-employee profitability for Google and MS:
It just so happens that 2006/7 and 2010 are charted as the minimum and maximum in this table. In essence, Google has pushed ahead over that period, and MS has stagnated … as if they’d had to change their plans.
There is/was a Capex justification to Android the programme for Google back then, but cash-rich companies with agreeable dominant shareholders don’t have to worry so much about that.
The Elephant in the room.
Of course Apple and iOS are the Elephant in the room. Google wants to take them on too. Steve jobs was famously angry about the Android announcement, but he perhaps should not have been as Google had invested in Android’s external development since 2005. Apple’s advantage was that they could fork OS X to make iOS. That and the fact that they had hardware manufacturing experience.
Apple did not threaten Ad revenue though, and that’s they key point.
Tom Dale suggested “Google is getting better at designing faster than Apple is getting better at web services” via Pat Gibson. I hope that continues to be true. Even though I only own Apple devices, it’s time for change as Apple are dreadful custodians of what they’ve made. The XCode/Objective-C toolchain is archaic and redeemed only by InterfaceBuilder.
Published at DZone with permission of Paul Hammant , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.