Do you remember Joel’s post from 2006 discussing how 24 people were involved in a trivial “Off” menu feature?
I was re-reading it (you can’t help but have a bit of a smirk as you do so) and thinking about the mammoth task at hand right now in Redmond.
Windows is an epic beast that has grown over decades. Now imagine taking the general large task of improving it and then adding the fact that each platform / fork needs to be merged for Windows 10. At a high level it is an easy thing to say:
“Look, we can’t have separate OSes for phone, embedded, desktop, server, Xbox, we need one experience to rule them all!”
Now imagine being the engineering teams. Think of all of the work that needed to be done to even understand what to do?
Each OS team understands their own world, and now they need to share and communicate that knowledge by mind melding with the other teams. Imagine all of the short cuts that were taken a long the way: “guys, we just need to fork that and make it work for Xbox… we gotta ship!” times a thousand.
This is a common pattern in the life of large projects. To move fast you want to minimize communication costs and have small teams with clear goals where the solution is mapped in their mind. If you get to a point where you want to converge the distinct efforts then the world stops as you collectively work out what to merge, what to scrap, and what to retool.
The more that you share and leverage, the more that you need to think about the abstractions; designing them to be flexible. You have to be better at predicting the future, which is really hard to do. At certain scales the standardization has been proven to be truly worth it (e.g. ARM, distributed systems on commodity hardware) but 99% of the time I have seen teams choose abstractions that were too restrictive and the so called leverage was wiped away with the communication and integration costs.
When you write code you tend to only refactor after the third usage. What is the appropriate equivalent for large scale abstractions?
One Platform To Rule Them All
Let’s say that there are three instances of a product. One path is to have three teams run at their own speed and write everything from scratch. They may choose to use the same low level stacks (e.g. they all use node running on AWS) and differ on others (some use PostgreSQL, Redis, React on the front end, others go with other options). Each team runs at full pace, but get no leverage from each other.
On the other end of the scale one team builds a full platform that has all of the features required for the three different products. Now you get to share a lot more, but you also have much pain in that the platform needs to fully morph. This approach can be great if the three products are very similar, but it can be awful if there are many differences. Once up and running you also need to work out how to prioritize across the products. If they aren’t balanced then it is very easy to end up with one product that is the most popular owning the bulk of the back log. In that case it sucks to be the other two. It can help to dedicate resources to each product, but then you are splitting on people resources vs. backlog work.
Apple and Microsoft
Windows 10 isn’t the only operating system in this dance. iOS was born in classic Apple style. A team was formed to go after the mission. They could steal people. They fork and run.
I have also heard that the org structure has changed a lot in the last few years. Consolidation has happened (e.g. one power management team to support iOS and OS X).
I don’t know about you, but I have felt like my recent Apple products have been less stable (both iOS and OS X). Is this just the weight of product development? It does feel like the teams are being pushed too hard. Those yearly releases must be brutal! But, I also wonder if part of the issue is pivoting to a more shared world.
One Adaptive World
Why is this work happening at the same time? You can see the argument:
It is time to have one adaptive computing platform. A unified experience. A unified store. The future isn’t a desktop and a phone. The future is connecting together inputs, compute, storage, and outputs.
This makes sense to me. My “phone” is a small scale compute, storage, inputs and outputs that are always with me, and it can connect to various external accessories to allow me to do more. Microsoft HoloLens (a.k.a 3d Bob!) is a glimpse to one aspect of another world of extensibility.
The future is exciting. Hopefully it won’t be the external dystopia of Ready Player One (I can’t wait to see the movie when it comes out!), but something greater outside of the matrix.
As we continue to build this future at an accelerating rate I will raise a glass to the engineers and teams who are having to go through grueling hard work to get there. Getting to the vision of Windows 10 is going to be a massive task, with beasts at every turn. These teams must be working on huge refactoring and rebuilding right at a time that there is intense pressure to ship cool new features and products.
My hat is off to you. Your companies future depends on you. Hacking on v1 is the easy part. What you are doing is the real work. The good news is that it has been done before.
Good luck.