Maxim Fridental

I’ve read a blog post by Olga Gromyko, who is a popular award-winning Russian and Belorussian writer and, one can say, one of the founders of a new genre of Russian literature (the humorous fantasy). And this post has resonated so well with the summary of my previous Anti-Pirate post that I’ve decided to translate it here (shortened and totally un-authorized). It is especially interesting, because Russia being one of the countries with the highest piracy level represents in my opinion quite well a possible future of Europe, if our Pirate party and other anti-DRM fighters would win the elections.

***

“We, writers, are often asked why do we depend that much on paper books. Without paper books our forests would be healthier and our shelves not so full. It is especially true, because [in Russia] mostly sub-optimal works are being printed, and the truly great ones are available in the Internet for free[…]

Alas, nowadays the success metric of a book is not its quality, and even not its readability, but its want-to-own potential.

The want-to-own potential depends partially on readability in the sense that a want-to-own book is almost always readable. Unfortunately, the opposite doesn’t hold. And while book readability can quite precisely be estimated by critics, the want-to-own potential cannot be predicted well.

Ten people would read youth fantasy by [some author] and remain not involved. But the eleventh one will drown the book in his own tears, and will camp before closed doors of the book store waiting for the next book. He wants this book, a paper version indeed, to be able to own it as an artifact and fetish, and will bind his emotions to this material paper book, which can be so tenderly hold against the heart.

An electronic book reader is unusable for this purpose. It is similar to a shopping mall toilet. And you want to close yourself in your own toilet, comfortable, cosy and well-decorated.

[The emotional binding to an artifact] is also the reason why fans are asking for autographs, and also for the fan service industry (t-shirts, figures, comics etc).

In fact, the highest influencer to the want-to-own potential is the author’s name, followed by the [popularity of] book series [your book is part of], and finally, by the [typographic quality of print, cover and binding]. Yes, yes, some readers would really buy books according to the color of their wallpapers. [Also, buying books as a present highly depends on the typographic quality].

The actual quality of the text does not correlate with the want-to-own potential. A smart, insightful and thought-provoking text will be read once, and never ever be read again, because it targets our brains, not our heart. Our brains are rational: you don’t need to buy a book if you are not going to re-read it again. That’s why publishers don’t issue such kind of books [a lot]. They are not profitable[…]

Similarly, the text can be interesting, humorous, entertaining and stuff, but if the book doesn’t have the want-to-own potential, it won’t be bought. “Yeah, this text is wonderful, I’ve read it the whole night, and I was laughing like crazy [… but I won’t buy the book, because it won’t be interesting to re-read]”

[…]

In the both cases, the situation can be improved dramatically if we had a stable and working market of (non-pirated) electronic books. But we [in Russia] don’t have it – 95% to 99% of all electronic books is downloaded for free from pirate sites.

This is also the reason, why [in Russia] the [emotionally binding] nyannyan books have won against [the other kinds of literary works].

[…]

I’d be glad to write electronic books. Just write the book, design it, upload and set the price – voila, profit. But!.. :) Even though my newest book has been downloaded by thousands and thousands of readers from a lot of pirate sites, its legal electronic version could bring only [under 300€] of sales. [You can’t afford writing books professionally, if you get only 300€ for them].”

***

Her blog post has already generated 509 comments :)

From my point of view, a similar situation holds also for the web sites. If you’re wondering why the hell you are forced to do this and that by a web site. If you are disturbed by ads. If you’re tired of spam. Consider how the Internet looked like if you had habit of paying some 2€ to 20€ montly fee for each of the sites you use daily.

Startup mode development is only possible for very small teams. It is not suitable for large projects. This is what I often hear as justification for introducing more formal development processes. So let’s play a large project scenario for Waterfall, Scrum and SMD and see how exactly SMD will loose this battle (I’m sure it will).

For starters, we need an interesting large project. Creating a big new product for a completely new market in a large project is a not very suitable example, because it is often bad idea economically. It is much more better idea to build something small, see market reaction, pivot, and iterate until you’ve found the product market fit. Unless you’re second Steve Jobs. Playing our scenarios for economically bad projects is not very interesting, because in these cases, typically, nobody is really interested in efficiency, quality, time-to-market, or any other metric of a development process.

No, let’s take an interesting case.

A web-site rewrite is such a case. Imagine we have a new cool product called Witter*, that has created a whole new market of micro-blogging. (*Note that I have no idea about how real Twitter was made and later rewritten. I’m just using it as example.) We have written our Witter using a decent dynamic language, that has successfully allowed us to find the market before we have burned up all of our investment money. Unfortunately, we have therefore all issues of dynamic languages, including problems with run-time performance, and we have an ad-hoc architecture limiting our scalability and availability. We want to rewrite Witter to solve these problems.

Waterfall

1. Specification Phase
Basically, we would start by describing the current state of the product, but some stakeholders – operations, usability specialists, designers, PMs will add some new requirements. Because the process requires a specification (in form of a written document), PMs will spend time not only describing what should be better, but also describing the current state.

Efforts: 200 man/days
Calendar time: 3 months, because all stakeholders will try to use the chance and add some features they’ve had desired for so long. Therefore, a lot of stakeholder meetings will be required.

2. Architecture Design Phase
If I were designing Witter for maximal run-time performance, I would first consider the data structure to hold the (t)weet feed of a single user. It must be extremely quick both for appending and for reading, and memory efficient. To avoid memory fragmentation issues and VM overhead, I would develop it in C (or C++). So, basically, the core of the Witter would be a service app written in C. When this core service starts, it would grab all available RAM and provide two interfaces: the one to add a weet, and the other to subscribe for weet stream. Core services will be sharded AND doubled so that the weet feed of one user is stored on exactly two hardware servers (for availability). When a new weet enters the system, it will be multicasted via UDP to all listening core services. Each service would check if it stores feeds of either the weet creator, or one of his followers, and if yes, it would add the weet into the corresponding feed. In case some consumers are subscribed for the changes for those feeds, the core service would push this change to all of them in order. I would model the persistance simply as one of the clients of this core service, which is subscribed to all feeds, and always gets pushed the changes first. When a change is pushed to persistence cluster, it would use some standard DB to store it. I’d provided a public-facing web service with an API required for a number of frontends, including the web frontend, mobile web frontend, iOS app, Android app and WP8 app. Internally, this web service would communicate with the core service and the persistence. The frontends would be developed fully separately, and share, if at all, only some basic CI and UX guidelines. On the server side, another two major building blocks to be mentioned is a OAuth authentication service, and a tracking and monitoring system presenting health and stats of all systems in a single dashboard. Of course, the task of managing of thousands of servers has to be considered as well as a number of scripts and solutions for commissioning and installing new servers, and software deployment. Most of the services would be sharded and load-balanced, and principles and ideas of “Release It” will be applied.

I would insist on building a working prototype of the most technically important parts of the system – the core service and the persistence, develop it, and measure its throughput and other run-time parameters to ensure they are of acceptable level.

Efforts architecture document: 30 MD; efforts prototyping and measuring performance: 30 MD
Calendar time: 3 months

3. Development planning
As a result of architecture phase, interfaces between parts of the system have been defined, so that teams can be build for developing parts of Witter, and they can start working in parallel. In total 9 teams will work on the re-write:

1) Core service team
2) Persistence team
3) Authentication service team
4) Web and mobile web frontend team
5) iOS frontend team
6) Android frontend team
7) WP8 frontend team
8) Monitoring and tracking subsystem team
9) Build, release, and rollout infrastructure team

Total team size: 40 persons.

Efforts for planning and kickoffs: 120 MD
Calendar time: 3 days

4. Development Phase
Here, all teams develop independently and in parallel. If needed, they create mock services or mock clients to be able to test their parts.

Efforts: 1500 MD
Calendar time: 2 months

5. Integration phase
All subsystems will get integrated together and bugfixed

Efforts: 800 MD
Calendar time: 2 months

6. Rollout
Because this is such a large project and this is the first rollout, there is no need to wait for next release window.

Efforts: 100 MD
Calendar time: 7 days

Total project efforts: 2780 MD
Calendar time: 10.5 months

Scrum

Let’s assume that the current implementation of Witter is a monolithic web app, consisting of a single Ruby file handling all requests, a bunch of static files, and a MySQL database, and that there is only a web frontend. When the frontend posts a weet using Ajax, it will be received by the server side. Then, all feeds that have to be updated will be determined by querying the database, then the weet will be saved into the receiving feeds. And when the frontend polls the feed using Ajax, the latest weets will be retrieved from the database and sent to it. Simple, trivial, and does its job. The whole thing is deployed on a single server.

Using Scrum for teams of 40 persons is usually not the best idea, so that realistically, one would do a little architecture considerations and planning upfront, and split the project into the sub-projects. On the other hand, the power of Scrum is in incremental delivery of business value. Therefore, the existing Witter solution will be incrementally rewritten.

For software developers, after some consideration, the following strategy will be agreed upon. All devs are divided into the infrastructure and application groups. The infrastructure group works on improving scalability and availability. The application group first introduces a public web API, and then several smaller teams work on implementing frontends in parallel.

The sprints will be set to 4 weeks, and will cost 80 MD each for the infrastructure group, the core app team, the web frontend team, the iOS team, the Android team and the WP8 team.

During the first two sprints, only technical changes will be made and the existing UX will be re-implemented as is, giving 8 weeks time for web frontend PM and designers to prepare user stories for the improvements. The mobile frontend PMs and designers are given 4 weeks time to prepare first UX deliverables.

The following sprints will be probably done:

1. Sprint
Infrastructure: posting a weet will send a message over message bus to a new core service written in Java, which will determine the proper target feeds and store it into MySQL. Reading weet feeds will also be done over that new service, to improve decoupling between the app logic and the database.
Core app: the first version of API will be introduced in form of a simple “if” statement in the Ruby file; responding with XML will be done in the same way as responding with HTML.
Web Frontend: Re-created the existing UI, moving a lot of server side code into the client and preparing for using the API.
Mobile Frontends: Installing the development environment, making prototyping for designers, registering in the corresponding marketplace, being idle.

2. Sprint
Infrastructure: a huge memcached cluster will be introduced to help with the problem MySQL being the bottleneck. The structure of users and followers is stored in the RAM completely, so that one can determine the proper target feeds without MySQL queries.
Core app: The pushing into the public web API is implemented as polling of the core service. The API is rewritten in Java.
Web Frontend: making frontend to actually use the API, first experiments with live pushing of weets.
Mobile Frontends: started implementing UI.

3. Sprint
Infrastructure: as the number of users continues to raise exponentially, teams pro-actively introduces sharding and load-balancing of all servers.
Core app: previously, the web API has relied on authentication cookie set by the Ruby app; a new OAuth service will be employed and the API v2 will be released.
Web Frontend: switching to API v2, starting to implement frontend improvements desired by PMs and designers
Mobile Frontends: Finishing to work on UI, introducing animations and making performance test on real devices.

4. Sprint
Infrastructure: the core service introduces subscriptions so that an incoming weet will be pushed into clients connected with the web API, without polling. Also, incoming weets will be stored first into the memcached cluster, and then picked up and saved into MySQL asynchronously by a separate process.
Core app: switching from polling to the new pushing scheme; the public API doesn’t change. Also, eliminating the last parts still implemented in Ruby, and re-writing them in Java
Web Frontend: Implementing frontend improvements. Communicating with the core app team to implement API v3 with enhancements needed for the new feature.
Mobile Frontends: Coupling the apps with the web API.

5. Sprint
Infrastructure: as network congestion between the core services and the memcached cluster is determined to be the new bottleneck, instances of core services and memcached will be bundled into the same physical servers and the system will be re-sharded so that one core server will only talk with one local memcached instance. Multicasting of incoming weets will be introduced.
Core app: Switching to the new message bus supporting UDP multicast. Started implementing dashboard for monitoring and tracking. Implementing web API v3.
Web Frontend: Finishing implementing frontend improvements.
Mobile Frontends: Implementing push notifications, wrapping the apps and submitting them into the corresponding marketplaces.

6. Sprint
Infrastructure: Java VM, Java GC and memory fragmentation are identified as the new bottleneck. Core services are being rewritten in C without changing their interfaces.
Core app: Finishing implementing monitoring dashboard.
Web Frontend: Profiling the site with YSlow and improving performance by doing magic with CSS and Javascript files.
Mobile Frontends: iOS team implements the iPad app version utilizing more screen space; Android team is busy with testing the app UI on huge variety of devices, WP8 team prepares with Win8 version of the app.

Total project efforts: 2760 MD
Time: 6 months

Although there was no need to spend time and efforts creating an up-front architecture documents, the cost savings were almost compensated by more work to do (infrastructure team first trying Java before finally resorting to C; Core app team having to upgrade to new versions of interfaces). The time-to-market is significantly better than in Waterfall, not only because the project is finished after 6 months, but also because the first scalability and availability improvements were already live after the first sprint (4 weeks), and monthly improvements have allowed the company to invite more and more users every months. On contrary, in the Waterfall model, the company would have to wait 10 months before leaving private beta status, which would severely endangered its market standing.

SMD

Note that according to the requirements of this scenario, we’re not allowed to grow the team (at least not too much), because the process will stop being SMD.

1. Jeanne: guys, I’ve analyzed the latest stats, and WE BEGIN TO BE VIRAL NOW!
Mark: HURRAY!
Tim: F*CK, WE’RE UNPREPARED AND IN A DEEP SHIT NOW!
An ad-hoc crisis meeting follows, where the following decisions will be taken:

• Development of mobile frontends will be outsourced. This means worse quality, but time-to-market is more important.
• All the servers and databases will be hosted in the Cloud. This is more expensive, but time-to-market is more important.
• Tim’s buddy Andy will be head-hunted. Andy works in Acebook infrastructure team, so that he has a lot of technical knowledge helpful for Witter.
• They will hire Brendan, who is a Javascript and HTML5 guru.
• Tim will concentrate on the API and ongoing operations, Andy will provide infrastructure, Brendan will work on the web frontend, Jeanne will lead UX development for all frontends, and Mark will be responsible for the project management of the contractors.

2. Next 2 weeks:

• Jeanne is preparing first mobile UX sketches
• Tim releases the very first draft of web API and uploads it on the Cloud
• Mark is sourcing good contractors for mobile frontends
• Team is waiting for the new guys to come

Efforts: 30 MD
Time: 2 weeks

3. Andy will develop the core service in C. First, he will create all needed data structures and algorithms, including writing a custom malloc, patching linux kernel and measuring performance. This will take him two months. He will then proceed with networking code. Unfortunately, POSIX contains API for networking, so he will use POSIX. After having experience with WinAPI, I have worked with POSIX and my feelings were not unlike of touching a fossilized mammoth shit. When POSIX was created, they didn’t know the word “usability” yet. This means, Andy will take another month for the, actually trivial, networking code. Finally, it will take him another month to add business logic and the code needed for logging, tracing and monitoring.

Efforts: 100 MD
Time: 4 months (in parallel with others)

4. Brendan will reimplement the web frontend using the latest HTML5 and JavaScript frameworks. This will speed up the frontend and make it to appear more responsive so that the scalability problems the team has won’t look so bad. It will take him a month. And another month for the mobile web frontend. He then start implementing desired new features, which will take another two months.

Efforts: 100 MD
Time: 4 months (in parallel with others)

5. Tim’s job is the most stressful. He will have to create web API to unblock Brendan and contractors, but on the other hand try to extinguish the most rampant fires caused by lack of scalability. First, he will split the MySQL database in one containing only the social graph, and the other with weet feeds. He will shard the latter based on userid. He will also split the Ruby app into the “Forwader” and “Feed server” parts. Incoming weets will hit the Forwarder system, which will be connected with the social graph DB. The Forwarder will decide what feeds have to be updated, and forward the incoming weet to the corresponding sharded “Feed” servers. Requests to read weet feeds will be sent directly to the corresponding Feed server. Having this basic scalability in place, Tim will deploy the system into the Cloud. In parallel, he will introduce a first version of the API (without push yet, but with some quick and dirty OAuth implementation). This will take him one month. Next, he will replace the social graph database with a MongoDB cluster, provision several identical Forwarder systems speaking with the same MongoDB cluster, and use the Cloud feature to round-robin the incoming traffic between the Forwarders. In parallel, he will implement the push for the API, because it just means the the Feed server has to trigger a push via COMET each time it saves a new weet in the MySQL. This will take him another month. Finally, he has to integrate with the Andy’s infrastructure. When he did the Forwarder, he has already explicitly decoupled the web API code from the forwarding logic, anticipating Andy’s work. Now, he will throw away the forwarding logic and just multicast weets to the Andy’s core service cluster. He will add code to the Feed servers so that they subscribe for changes pushed from core services. And he will need to re-implement the push functionality in the API. This is a bigger change, and this will take him 2 months.

Efforts: 100 MD
Time: 4 months (in parallel with others)

6. The 3 contractors will need 4 months each to implement the corresponding mobile apps. They will bill 100000€ each. Mark will need to spend at least half of his time managing them.

Efforts: 300000€ + 50 MD
Time: 4 months (in parallel with others)

7. Jeanne will spend her 4 months creating and discussing UX for three different mobile platforms, and creating and discussing web frontend UX improvements. In the “spare” time she has to work as community manager trying to respond on angry user mails who are not satisfied with the service’s current stability and availability.

Efforts: 100 MD
Time: 4 months (in parallel with others)

Total project efforts: 450 MD + 300000€ + expenses for the Cloud
Time: 4.5 months

SMD costs just around 30% of Waterfall or Scrum expenses, and its time-to-market is 1/3 lower than that of Scrum. One of the reasons for this efficiency is a tiny team co-located in one small room. This reduces possible time waste for technical discussions, misunderstandings, creation of documents, and office politics. Another reason is partial use of contractors, because their business model is streamlined for efficient creation of mobile apps, and they typically have building blocks they can reuse from customer to customer. Also, because of such a small team, many things will be done in a quick-n-dirty way, meaning it will be hard to maintain and evolve them in the future, unless more investment will be done in rewriting them yet again. But the main reason, and at the same time showstopper for many startups, is hiring programming gods to accomplish the task. Andy, Brendan and Tim from this example are all extremely efficient, extremely knowledgeable gurus. It is very hard to hunt such persons for your small startup. Especially if you’re situated not in the Silicon Valley. And it is even harder to get these guys on 2-week notice, exactly at the moment you’ve recognized that your startup is getting traction.

And if you cannot afford working with best of the breed, you are forced to work with whatever software developers are available. Those devs are by no means less smart than gurus – they just don’t have so much experience yet, and perhaps, not so much dedication. This means, on average, you need more of them. And at the moment when you have too many devs to be comfortable with in a single room, you have to introduce processes, and here you go, you have Scrum in your company, even though your product is just a small website.

I remember the time looking in the eyes of a manager who was so happy telling me he has grown the company and hired a lot of new devs, and I was thinking, like, shouldn’t you feel a bitter drop of failure in your jar of honey?

Summary

SMD was still a preferable way to develop software also in this example of a larger project. Unfortunately, it is very hard to follow it, and it has additional implications (like heavier reliance on contractors and Cloud services, as well as a tad worse truck factor).

Just to remind you of a real-world example: Instagram had achieved 30 Mio users with only 13 employees (now they have 100 Mio). I have no idea what process they are using, but I doubt it is a formal one.

China playing ever increasing role as economic power and taking ever larger share of mass media topics, it is to be expected that the Chinese language and Chinese sites will appear in the international Internet consciousness. As far as I can tell, so far nobody has really made it, although I believe there are a lot of people who at least have heard about the Taobao and the Baidu, and perhaps much less people have heard about the QQ, RenRen or Xiaomi.

Socialba! is apparently another newcomer trying to go international. As far as my limited Chinese knowledge can help, it is actually meant to be called Social??, and can be roughly translated as “Let’s go social” or “Social indeed”. This is just a plugin allowing to post something once on one social network and have it automatically distributed on all other networks.

I’m a big supporter of the idea of federated socal networks (or social meta-network), and such a service could be one possible way to go, but I wouldn’t recommend using that particular site just yet. In particular, its privacy policy is very interesting to read, especially a couple of last paragraphs copied verbatim from Pinterest (why do I know? Because they have overlooked one of two instances of word ”Pinterest” in the text). Also, the only contact information about the people behind the site is a google mail address. I’m not saying this site is malicious, but they currently did only a poor job convincing me of the opposite.

Children bikes are equipped with detachable training wheels. Training wheels are very helpful on the initial stages, when you have to accustomize yourself with the speed you’re moving around, and how to get on or off the bike, and how to brake, and how to turn, and how to avoid obstacles, and how to check environment around you before you make a sharp brake or turn. But when it is time to approach the actual bike usage pattern – getting to the actual bike speeds – you have to detach the training wheels and learn how to balance.

I have almost similar feelings about statically typed programming languages. They are great for exactly four things:

• Learning the frameworks and APIs (due to auto-completion features)
• Protecting yourself from typos
• Achieving maximal run-time performance
• Allowing more automatic refactorings

Run-time performance is rarely important in the world of app development (remember my RAD vs CS article?). Automated refactorings are very rarely needed in the modern web development, where 95% of apps are rarely allowed to grow older than a year. That’s more an attribute of enterprise software having decades of legacy code. As for the first two advantages, they are indeed great for the novice programmers, or for programmers switching platforms and languages.

And this is what TypeScript is all about, and therefore I believe it could be a help for programmers who want to migrate from statically typed languages to JavaScript. Its creator Anders Hejlsberg (who also created Delphi and C# before) gave a talk about it on the //build conference:
http://channel9.msdn.com/Events/Build/2012/3-012
And I believe this talk is every second worth to watch. The thing is that Hejlsberg doesn’t really appreciates all advantages of the dynamically typed languanges, only makes this talk more interesting and sometimes funny. For example, as he presented the type inference of the process function, I couldn’t resist opening the TypeScript playground in another browser window, and typing

function process(a: bool) {
  if(a)
    return 1;
  else
    return "haha";
}

This has been marked as an error in TypeScript. This and also many other examples can show you that if you use TypeScript, you will actually be forced to reason about the source code as if you’ve had used C#. And this means you’ll lost some of the advanced JavaScript features – those wonderful dynamic features that would bring you up to the actual speed.

In any case, I can’t deny that auto-completion would be a great help for me to learn, say, jQuery or Node.js, or WinRT frameworks, if I needed to. I also like the look and feel of the TypeScript syntax, which is in parts quite similar to C#; actually, some of the TypeScript features I wanted to have in the C#, for example type checking based on object structure (so that I could pass anonymous objects to functions expecting named types), or the notion of interface as the combined structure of all interface definitions from all included source files.

TypeScript is also a perfect example of the New Microsoft. It is free. It is open source. It embraces open standards (EcmaScript). It doesn’t bind you to any other MS products (although it is integrated with Visual Studio, nothing prevents, say, Eclipse or JetBrains to integrate with it too). This is not the first such example and not the last one, and this change has happened not this year, and not in the previous year. This has changed at least 5 years ago. I just wonder when the geeks will realize that. Until that, the New Microsoft will remain an insider tip.

Here are my impressions after watching the key note of the //build conference:

• The family of Windows 8 operating systems spans across the whole spectrum of devices: huge touch panels, all-in-one desktops, notebooks, netbooks, tablets, phones, and in some sense XBOX.
• When you write a Win8 app, it means it will run on any of aforementioned devices. I’m not sure about technical details, whether there is literally no need to re-compile, or there are some relatively easy changes (like SL vs WP7 apps two years ago); in any case, it means that the bang for every buck you invest into writing a Win8 app multiplies proportionally the number of different form-factors supported by Win8. Of course you need different UX according to the screen size and other hardware details, but I believe, with a careful planning and utilizing ideas of responsive design, it is still possible to achieve quite an impressive multiplication factor.
• And this is different from the competition. In Google ecosystem, you either write Dalvik apps (are we allowed to call them Java apps anyways?), which could perhaps run on Google-TV, but won’t run on PC and notebooks. Or you write native Android apps, which are, well, native to Android. In Apple ecosystem, the same applies for iOS apps that can’t run on computers. The only chance to get the multiplication effect is to use HTML5. But then you’re locked in the HTML paradigm (pages instead of apps), and performance and battery issues of JavaScript. Those ecosystems were designed chaotically, incrementally and mostly driven by market demand and feedback from the crowd. Designers of the Win8 ecosystem seem to have learned the lessons, and re-implemented the product line, in architecturally clean and reasonable way. A button is a button, no matter if it is on desktop, tablet, or phone. You can write the same markup and same code for any of those hardware platforms, as soon as there is no UX consideration against it.
• But you don’t have to use the same technology for everything. Microsoft has learned lessons of .NET Framework in an impressive way. This means, you can still use C# for the apps. Judging on its features, C# is like Java, if Java have had been actively improved in the past 10 years. But you can also dive deep and use C++ and DirectX, for the maximal run-time performance. This means, Win8 apps can come as close to the bare hardware as it gets. And, you can use HTML5 and JavaScript, it case you care more about time to market and rapid software development. No matter what language do you use, you still has exactly the same API and frameworks to communicate with the OS.
• Integration, Integration, Integration. Microsoft has always been about achieving excellent productivity via integration. Only after having used Microsoft Outlook without Microsoft Exchange and Office Communicator, and Windows without AD and single sign-on, I’ve learned to appreciate the significant synergy effects when you use different Microsoft products together. Also in this case, Ballmer has demoed a very deep integration between different Win8 devices. He has virtually said that the Win8 phone is THE phone a desktop Win8 user would wanna have. And I see how he means it.
• Money, Money, Money. Microsoft has always been about earning money by providing platforms for others to earn money. They have the best know-how in this area, and you can feel it right away. Optional in-app payment engines is just one example.
• And last but not least, I appreciated how Ballmer and other guys on the scene were looking. You know, all these Apple and Google events, with presenters if not outright metrosexual, then at least deeply caring about the cool clothes and shoes, and having cool hair-cut, and being manicured… I mean, yeah of course I would like to look as cool as they do. But I won’t achieve it by buying an iPhone or Nexus. Therefore, that’s actually the same kind of fad that the fashion industry is doing with the supermodels. The only reason why we the geeks don’t detect it is that we’re mostly both male heterosexual and introverted, and the idea to evaluate the exterior of the presenters doesn’t come into our minds. On the other hand, on the //build/ I saw just the normal guys, having normal to slightly high BMI, wearing normal clothes and caring about them not more than a normal geek does.

PS. If I have time, I will also watch the following sessions:

Introducing TypeScript: A language for application-scale JavaScript development

Modern JavaScript

Super-Natural Interaction

Designing great reading experiences

and skim through some other presentations.