For me, the big "hell no" to CD was when my boss received a phone call from a customer who was screaming and crying because we added 1 button to the UI for a requested feature. This change was the last straw for this particular user, and after rolling back the change, our customer agents collected user feedback and we got a very important backhand across the face from reality...
We used to practice 2 week deployments with a roadmap to get onto a full CI/CD workflow so that, even with feature flags, we could roll out changes quickly. After we almost lost our largest client over a button, we pulled back to a quarterly deployment compromise since many of our customers were adamant that we should do less updates, as few as once a year in some cases. What we took away from this event was end users DO NOT WANT CHANGES; when they have their own work to do, they don't have time to learn new features every week, day, or god forbid every hour. This is not a matter of fear, it's a matter of compassion for your end-users' time.
Another thing to consider is regulatory compliance. In some industries (like healthcare in the US) you have to certify your software, and major "feature" modifications trigger a significant and costly recertification process. Adding new features more than a few times a year could drive small businesses out of business with the $20k and up fee per recertification.
This confirms my belief that CD is driven almost entirely by parochial MIS departments wanting to jump onto the latest devops craze or improve their own processes. I would be interested to know if anybody has seen quantifiable real world benefits experienced by uses outside of the IT department.
Software Delivery Futurist.
Chief Storyteller at https://perfectscale.io.
CEO and founder at https://otomato.io.
Co-founder at https://stagecentral.io.
"lost a client over a button" is surely a scary story! but wouldn't a better approach be making sure each client only gets the changes they need? CD isn't necessarily about new features. It's also about fixing bugs, improving performance and continuously paying off our tech debt. It's also about being able to roll things back quickly when the shit hits the fan. Once we're able to do this - we'll have our client's trust and won't fear losing them over a button.
IMO this a product/leadership horror story, not necessarily a technology horror story. The issue is that the right feature wasn't built – or it was built in a way that required new processes from the customer. When that happens, the methodology and timeline of its release isn't the cause of the failure – it would have always been poorly received. There is a missing 'product' role here – a person or team that is in constant conversation with the customer and ultimately responsible for features make it into the product.
You're right on about compliance. So a CD "culture" or structure isn't a drop-in solution for every business. Some industries simply should not be releasing new ui changes or features all the time.
CD isn't always about features, though. Sometimes it's about performance, security or technical debt. In fact, a trusted CD process is a potential solution to this type of "bad feature" issue, allowing for fast backpedaling.
When talking about features, it is totally true that customers don't want change. They don't even want the "product", what they want is what your product enables them to achieve. They're hiring your product to get their job done. Compassion includes being on that journey with them when scenarios change.
An example: your customer's industry has a new legal regulation that requires them to change how they work (or let's say, a global pandemic occurs and changes everything 😉 ). In this scenario, compassion for the customer means anticipating their needs, and releasing changes as quickly and confidently as possible – as the situation evolves. This responsiveness is what CD enables.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For me, the big "hell no" to CD was when my boss received a phone call from a customer who was screaming and crying because we added 1 button to the UI for a requested feature. This change was the last straw for this particular user, and after rolling back the change, our customer agents collected user feedback and we got a very important backhand across the face from reality...
We used to practice 2 week deployments with a roadmap to get onto a full CI/CD workflow so that, even with feature flags, we could roll out changes quickly. After we almost lost our largest client over a button, we pulled back to a quarterly deployment compromise since many of our customers were adamant that we should do less updates, as few as once a year in some cases. What we took away from this event was end users DO NOT WANT CHANGES; when they have their own work to do, they don't have time to learn new features every week, day, or god forbid every hour. This is not a matter of fear, it's a matter of compassion for your end-users' time.
Another thing to consider is regulatory compliance. In some industries (like healthcare in the US) you have to certify your software, and major "feature" modifications trigger a significant and costly recertification process. Adding new features more than a few times a year could drive small businesses out of business with the $20k and up fee per recertification.
This confirms my belief that CD is driven almost entirely by parochial MIS departments wanting to jump onto the latest devops craze or improve their own processes. I would be interested to know if anybody has seen quantifiable real world benefits experienced by uses outside of the IT department.
"lost a client over a button" is surely a scary story! but wouldn't a better approach be making sure each client only gets the changes they need? CD isn't necessarily about new features. It's also about fixing bugs, improving performance and continuously paying off our tech debt. It's also about being able to roll things back quickly when the shit hits the fan. Once we're able to do this - we'll have our client's trust and won't fear losing them over a button.
IMO this a product/leadership horror story, not necessarily a technology horror story. The issue is that the right feature wasn't built – or it was built in a way that required new processes from the customer. When that happens, the methodology and timeline of its release isn't the cause of the failure – it would have always been poorly received. There is a missing 'product' role here – a person or team that is in constant conversation with the customer and ultimately responsible for features make it into the product.
You're right on about compliance. So a CD "culture" or structure isn't a drop-in solution for every business. Some industries simply should not be releasing new ui changes or features all the time.
CD isn't always about features, though. Sometimes it's about performance, security or technical debt. In fact, a trusted CD process is a potential solution to this type of "bad feature" issue, allowing for fast backpedaling.
When talking about features, it is totally true that customers don't want change. They don't even want the "product", what they want is what your product enables them to achieve. They're hiring your product to get their job done. Compassion includes being on that journey with them when scenarios change.
An example: your customer's industry has a new legal regulation that requires them to change how they work (or let's say, a global pandemic occurs and changes everything 😉 ). In this scenario, compassion for the customer means anticipating their needs, and releasing changes as quickly and confidently as possible – as the situation evolves. This responsiveness is what CD enables.