The three year release cycle meant we rarely knew what the competitive landscape and external ecosystem would look like when we started a release […] What we thought we knew three or four years ago when we planned a given OS release was laughably outdated and sometimes flat out wrong when the product finally shipped.
The best thing we could have done was to enable incremental and friction-free delivery of new cloud based services to an ever-simplifying device. Instead, we kept adding features to an existing client-based monolithic system that required many months of testing before each release, slowing us down just when we needed to speed up.
This is precisely what I love about the web: you can have multiple releases on a (more than) daily basis, pushing out small incremental changes.
The end user always has the latest version.
Thankfully we’ve also moved this way when it comes to software: things like evergreen browsers which update themselves, and automated build pipelines continuously delivering changes to your test and end users (think of your Facebook/Instagram apps updating on a bi-weekly basis) are common nowadays.
When it comes to an OS and/or software libraries it becomes more complicated though. As Ben put it:
We didn’t dare remove old pieces of functionality which were needed in the name of compatibility by applications already running on previous releases of Windows.
I especially like how the React team is handling these kind of breaking changes: a feature is first marked as deprecated for 2 release cycles before it is actually removed, giving you – the developer using it – the time to adapt:
Of course it’s not really fair comparing OSes to React: developers using React can opt-in to upgrade to a new version. When it comes to an OS it’s the user – not the developer – that decides to upgrade or not. However, if you’re making software for a living you should prepare yourself for things like this (knowing that breaking changes in OSes are prevented as much as possible) and build things as Future Friendly as possible.
Did this help you out? Like what you see? Consider donating.
I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!
Every time you don’t write software based on the best possible practices and understanding of the business domain, you incur it in a technical debt. This debt keeps increasing over time, just like an interest, because whoever has to change something has to deal with the imperfect concepts you codified on the first occasion. If you ignore it long enough, you can go technically bankrupt, where the codified concepts do not reflect anymore the domain you’re working on.
Let’s take a hike on the coast from San Francisco to Los Angeles to visit our friends in Newport Beach. The line is about 400 miles long; we can walk 4 miles per hour for 10 hours per day, so we’ll be there in 10 days.
One day later:
Wow, there are a million little twists and turns on this coast. A 40-mile day will barely get us past Half Moon Bay. This trip is at least 500, not 400 miles.