Are Software Shipping Times Slowing? Folks, is it just me or do software engineers all around the globe stopped shipping real stuff?
I seriously need a calibration point. Either I’m finding myself in weird “echo chambers” in the past year, where a clever thing is said here and there from time to time, but no real delivery happens and the managers are seemingly okay with that. Or it really is a worldwide trend.
For my professional trajectory, as well as my personal mental health, it’s really important to make the right decision: do I need to prepare for the world where everyone is slower to ship, or do I need to optimize who to be next to more aggressively?
Because if it’s the former, I’ll just position myself at where I can find joy in hacking stuff up on my own and be safe & secure, as my soft skills and my meetup would take care of the rest. But if it’s the latter, then more rapid and more immediate actions are evidently required from my side before it’s too late.
My main concern is that planning estimates for shipping real things appear to be in quarters and years, not weeks and months.
It depends on how big the things are. I see some deliveries happening in days and some happening in years.
I do feel that dependencies are taking too much time though. Such as when a dependent project changes something and I have to spend lots of time adjusting to those dependencies.
Or when a dependent project refuses to fix actual bugs and I have to spend time implementing workarounds, then fix bugs in workarounds, then fix regressions in workarounds when a change in underlying dependency A mandates a change which broke a workaround for a bug in dependency B.
Sometimes I wish we could implement a feature freeze for a set of dependencies and then only fix bugs in those and not have to deal with changes which aren’t bug fixes. That would leave more time for implementing features in the actual application.
If we consider all different software products – we have deployments every day (we just consolidate and our deployment process takes more than one week to finish).
I guess it’s all about the scale and nature of the deployment. You can’t annoy customers by updating downloadable software every day, but you can make changes to the website as often as you want. Also you can’t ship quality downloadable software every day.
What you really want is a steady and reliable process. Again, if you take a huge company with 10’s of thousand developers and 100’s of products. You can say that there is a deployment every day. But that’s not the point.
If you batch up all of the changes from a month. And release them all in one go it’s very likely that at least one of those changes has introduced a bug.
Releasing each of those changes once it’s ready to go doesn’t necessarily change the number of bugs you ship. But it makes it easier to find out which one of the changes introduced the bug.
Even though you release frequently it doesn’t mean you have to ship changes without proper testing. Each of those changes can have gone through lots of testing. But merging and releasing smaller changes at a time is less likely to introduce bugs.
The entire process of deploying changes to customer equipment after it has been released is an entirely different story. When I said 10 deployments per week I was referring to a service hosted on servers under our control.
Shipping code to customers is more challenging for many reasons. In particular you have to actually ensure that you are aligned with user interests.
If all you need to ship that way is bug fixes it’s less of a challenge. Users shouldn’t be saying no to receiving bug fixes. But there is the question of how much your users trust you and how much you inconvenience the users.
It’s best if the bugfix can be installed without interrupting the user’s workflow in any way. But if a user has to close a browser or restart a computer to apply a bugfix it’s inconvenient and users will want to postpone it.
If you ever ship a bugfix which introduces a new bug you’ll lose some of your users’ trust in you. And that will make it harder to get them to apply bug fixes in the future.
If you ever ship a change among the bug fixes which is not in the user’s interest, then you will lose even more of that trust. For example if an application was to ship an update that blocked the user’s access to some content. And the user installed that in the belief that it was a bugfix, then that application is no longer worthy of user trust.
And if you ship a change that introduced ads in the application when the user thought they were getting a bugfix, then you will also lose user trust. Those kinds of things can get users to stop installing updates.
And if you ship a new version which changes behavior to be different from what the users are used to it will inconvenience them. And if you remove functionality that you no longer want to maintain. As a result, you will also have users who are not happy with installing updates.
Another problem is if you ship an update that increases resource usage. This is particularly bad if the user can no longer use the app on their current hardware. Or if it becomes measurable slower.
Many of those points wouldn’t be as much of a problem if users always could downgrade to any previous version. In that case the user runs a much smaller risk by installing the update. But, often that step back is not available.
