3 ms·

It really doesn't matter how robust your internal processes are or how good your QA team is. Some issues will slip through, and will be seen at very inopportune

It really doesn't matter how robust your internal processes are or how good your QA team is. Some issues will slip through, and will be seen at very inopportune times, after the system has had time to soak for a bit. By all means deploy to staging on Friday and have some automated and load testing running on weekends if that's what you want to do. But there's really no reason that promotion to prod should happen in a Friday or just before any significant time off. It really doesn't have much of a justification. You want to "feel good" about your work week and ship on a Friday? Ok great. How is that benefiting your customers? It's not urgent, it can wait until Monday or what have you.

nightski 4y ago
Not everyone ships software that is used by customers. In fact I'd imagine most software is not customer facing. It's all about context and in some cases a bug getting through really isn't a huge deal. Some times users would rather have the functionality even if it means the potential of bugs vs. none. There are very few hard rules with engineering.
- smachiz 4y ago
  Almost all software is used by customers - they might just not be paying you. Not understanding that your internal users are your customers is a mistake.
  - benj111 4y ago
    While I agree with the point, I dislike being described as a customer for non commercial transactions.
  - nightski 4y ago
    I disagree. We are all on the same team and I view them as team members. That doesn't mean I treat them any less important. Actually I view them as more important in some cases. But internal users may be more tolerant of bugs if it means they can get features faster. Our team is a lot more understanding and accommodating and want to work with you which is a very different relationship than a customer. But maybe that is because we have built up a lot of trust over the years. Really it's up to you and your team members to decide this. Like I said, no hard and fast rules. But it's also a failure when being slow with tech due to fear of a few bugs can hold back the entire company. Some bugs are showstoppers (bring down the system type of things). Others are very inconsequential. It's up to us as engineers to figure out how to use that context to avoid the first type, but make informed decisions about the second type. To be honest in 15 years of working with my current teams we have never had a bring the system down type of bug. It just doesn't happen.
throwbadubadu 4y ago
You two both shouldn't generalize but change perspective at times (:

nightski 4y ago

Not everyone ships software that is used by customers. In fact I'd imagine most software is not customer facing. It's all about context and in some cases a bug getting through really isn't a huge deal. Some times users would rather have the functionality even if it means the potential of bugs vs. none. There are very few hard rules with engineering.

smachiz 4y ago
Almost all software is used by customers - they might just not be paying you. Not understanding that your internal users are your customers is a mistake.
- benj111 4y ago
  While I agree with the point, I dislike being described as a customer for non commercial transactions.
- nightski 4y ago
  I disagree. We are all on the same team and I view them as team members. That doesn't mean I treat them any less important. Actually I view them as more important in some cases. But internal users may be more tolerant of bugs if it means they can get features faster. Our team is a lot more understanding and accommodating and want to work with you which is a very different relationship than a customer. But maybe that is because we have built up a lot of trust over the years. Really it's up to you and your team members to decide this. Like I said, no hard and fast rules. But it's also a failure when being slow with tech due to fear of a few bugs can hold back the entire company. Some bugs are showstoppers (bring down the system type of things). Others are very inconsequential. It's up to us as engineers to figure out how to use that context to avoid the first type, but make informed decisions about the second type. To be honest in 15 years of working with my current teams we have never had a bring the system down type of bug. It just doesn't happen.

throwbadubadu 4y ago

You two both shouldn't generalize but change perspective at times (: