I’m sitting here watching my iPhone update to iOS 11.0.1. Apple says that there are just a couple of fixes: some security updates and a fix for the Exchange email problems.
The update is sure taking a while, though. That’s consistent with my knowledge of how software development works. Color me skeptical that the first point release of a new iOS only has a couple of changes. My bet is that there are hundreds of fixes for all sorts of problems reported during the beta, but weren’t large enough to stop the release.
Development of software like Apple’s iOS or VMware’s vCenter never stops. At a certain point someone takes a snapshot of the way it looks and decides that it acts correctly enough to ship. Out the door it goes, called 11.0.0, or 6.5.0, or whatever.
Behind the scenes development never stops, though. People keep reporting bugs and the development groups keep fixing them. Most of the problems they fix will never be known to the end users. If you had a bug open with Apple or VMware you might find out that it’s fixed in a particular release, but without that particular inside knowledge you’d never have known.
What you do see is build numbers and version numbers, though, assigned to the snapshots that became releases.. Read the notes for a point release of VMware vCenter and there will be a handful of problems resolved and one or two new features added. The build number of vCenter will jump by 387,000, though. Nearly 400K builds for a few changes? Yeah, right. In this particular case (vCenter 6.5.0 build 5318154 to 5705665) that’s around 6500 builds a day. Something else is clearly going on.
To me, these are the ripples on the surface that belie the chaos underneath. It’s nice to think of products like iOS or vSphere as a glassy lake our IT boats can glide across, but it is more productive for us to remember that under the surface are the software equivalents of fallen trees, sandbars, litter, and dead fish. The people with the nets pulling the dead fish out sometimes fall in, too. Sometimes we get new software bugs in the fixes for other problems.
That’s why I always laugh at the people who say “if it ain’t broke don’t fix it.” Truth is that it’s all broken and we’ll never know just how bad the situation really is. The best thing we can do is move forward. Keep current on our patching, stay responsibly close to the current major version. Build and use test environments. Grow into new initiatives and deployments. Test our backups and DR.
And wear personal floatation devices for when our boat hits a rock.
I have to think Apple and VMware are doing some form of automated build and testing and 6,700 builds a day is reasonable for large projects doing continuous integration. Consider that their automation could be building many editions of their software, as ours does, and 10,000 builds a day is easy
I agree. I assumed that the builds are tied to checkins, though, rather than just a continuous loop or anything.