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!
A common misconception is that a software bug is called a bug because of an actual bug that was once found.
The story goes that Grace Hopper found a moth stuck in Harvard University’s Mark II calculator in 1947 and that she taped it inside a logbook with the words “First actual case of bug being found”.
In reality Grace herself didn’t find the bug – somebody else from the team did – nor did they coin the term bug because of that event.
American engineers have been calling small flaws in machines “bugs” for over a century. Thomas Edison talked about bugs in electrical circuits in the 1870s. When the first computers were built during the early 1940s, people working on them found bugs in both the hardware of the machines and in the programs that ran them.
What seems to be legit however is the history of the term software patch. Back in the day when punched card coding was all the rage (although …), one actually had to put a patch of tape/cardboard over a wrongly punched hole in order to fix a bug.
Historically, software suppliers distributed patches on paper tape or on punched cards, expecting the recipient to cut out the indicated part of the original tape (or deck), and patch in (hence the name) the replacement segment.