It’s a great post and often what I see folks doing.
Hot take though: why do we need so many people and processes and mysticism around software these days? It seems to me the reason why it’s so difficult to ship anything, let alone anything good and useful, is because there are so many people involved who don’t actually participate in engineering. They manage time lines and meetings and emails and talking to customers. And somehow they’ve made themselves essential to the process so that developers can’t ship code anymore.
Like… I know my users on a first name basis. I know how their business works. We’ve talked about the button and we want to run an experiment.
As a developer I might want to just try it out with them. Maybe the change will be a good fit for the product as a whole, maybe it will be a solution that only works for this one customer, maybe it means we need to be able to configure which workflow is used.
If I can’t just ship that and get the feedback I need without involving a handful of other people and being completely fearful that I could take down our service… what is wrong here? Is it that there aren’t enough “shippers” on the team or is it because the organization has made it difficult to ship anything?
That being said, this is the world we live in, and the article has a lot of great advice. I’m definitely used to/conditioned to think this way.
It sounds like you are part of a pretty small business given that you're an engineer who knows his customers by name. It may very well be completely acceptable to your customers to have extended downtime, or a button that disappears during a deployment leading to a broken feature for a couple of days until you, or they, realize something is wrong.
Many other companies do not work this way. If you're a huge company like Apple that makes $40M per hour, that type of downtime isn't acceptable. If you're in finance, that downtime doesn't work. If you're in healthcare, defense, aerospace, etc... that downtime doesn't cut it. Yes, you'll still have downtime in those industries from a bad deploy, but you put more checks and balances in place to reduce the odds it will happen.
I'm not actually at a company where I know folks by name at this point. I was for a time.
I currently work at a much larger company where I ship platform-related stuff that integrates a bunch of systems (card payment processing... so fintech) for other developers so that they can ship features and products to customers. I've done a lot of the work mentioned in the article.
The hot-take is just a suspicion that we make things more difficult for ourselves by involving more people than is necessary to get work done, not trusting developers, etc.
Update: and is more a reflection about how the industry operates in general than how things operate where i work in particular
> If I can’t just ship that and get the feedback I need
As a user, I detest when I'm treated as a lab rat and the software I rely on to get stuff done has the UI randomly changing because the people making it don't have anyone in charge with enough design sense to make a call on how the product should function.
Google normalized this practice with the obsessive A/B testing and it's one of the biggest things that pushed me away from Android and general Google services. Microsoft is terrible for it too now. Every piece of software feels like a perpetual beta test.
As a person who regularly ships software to folks to solve problems I think this is more of a symptom of marketing and product folks taking over than software developers trying to provide a stable, useful solution.
A system needs to change over time as demands and requirements change… but it shouldn’t be unexpected and without warning. And it should be in concert with knowing the unique demands of the users involved with the system.
When I want to run an experiment, I mean to run a deliberate experiment that the people using the software are aware of and are a part of. Not some random trial A/B test based on telemetry. That stuff is too common these days, I agree.
Hot take though: why do we need so many people and processes and mysticism around software these days? It seems to me the reason why it’s so difficult to ship anything, let alone anything good and useful, is because there are so many people involved who don’t actually participate in engineering. They manage time lines and meetings and emails and talking to customers. And somehow they’ve made themselves essential to the process so that developers can’t ship code anymore.
Like… I know my users on a first name basis. I know how their business works. We’ve talked about the button and we want to run an experiment.
As a developer I might want to just try it out with them. Maybe the change will be a good fit for the product as a whole, maybe it will be a solution that only works for this one customer, maybe it means we need to be able to configure which workflow is used.
If I can’t just ship that and get the feedback I need without involving a handful of other people and being completely fearful that I could take down our service… what is wrong here? Is it that there aren’t enough “shippers” on the team or is it because the organization has made it difficult to ship anything?
That being said, this is the world we live in, and the article has a lot of great advice. I’m definitely used to/conditioned to think this way.