On release cycles and deprecating stuff

From “What Really Happened with Vista: An Insider’s Retrospective” by Ben Fathi:

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!

☕️ Buy me a Coffee ($3)

Technical debt 101

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.

Technical debt 101 →

Why are software development task estimations regularly off by a factor of 2-3?

coastline

A “How Long Is the Coast of Britain?” alike answer to estimating how long software development will take.

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.

And it gets even better as the trip continues …

Why are software development task estimations regularly off by a factor of 2-3? →

xip.io – Wildcard DNS for any IP address.

xip.io is a magic domain name that provides wildcard DNS for any IP address. Say your LAN IP address is 10.0.0.1. Using xip.io:

  • 10.0.0.1.xip.io resolves to 10.0.0.1
  • www.10.0.0.1.xip.io resolves to 10.0.0.1
  • mysite.10.0.0.1.xip.io resolves to 10.0.0.1
  • foo.bar.10.0.0.1.xip.io resolves to 10.0.0.1

…and so on. You can use these domains to access virtual hosts on your development web server from devices on your local network, like iPads, iPhones, and other computers. No configuration required!

Now that’s pure genius! How come no-one else ever thought of that before?

To get this working in MAMP Pro, select your vhost, go to the advanced tab and enter ServerAlias project.*.xip.io in the Customized virtual host general settings-field.

Test it out by surfing to http://project.127.0.0.1.xip.io on your local machine. If for example your IP is 192.168.0.11, you can access it from other machines via http://project.192.168.0.11.xip.io

xip.io →