Hacker News Reader

Comment by boredumb | Hacker News Reader

Shipping code on Friday is bad. Shipping things after 4PM is also bad.

Why hire any QA? Why code review at all? All of these reduce the risk of bad or unintended software being in the wild and not releasing on friday or after 4pm reduce the amount of time it can be in the wild without harassing people who are otherwise on their off time. You can have a half dozen full time QA people and a horde of reviewers merging in your request into a staging instance that triggers E2E tests that complete and require a manager to merge into master to be automatically deployed via the same docker image into a cluster and the only guarantees you have is that it may be absolutely correct and that it may have an issue.

View on HN

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.

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.

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.

While I agree with the point, I dislike being described as a customer for non commercial transactions.

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.

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

Hear hear. Shipping at 10am Monday-Thursday is heaven, almost every single incident requiring immediate attention occurs during business hours.

Absolutely, the benefits of this approach far outweigh the downsides— and/or benefits of other approaches.

Also, I presume lot of people like Fridays to be bit more relaxed, over trying to do something stressful like a release.

From a more pessimistic perspective, as times goes -- code will likely get more messy and you'll likely have more customers (assumings things are going good), in which case the fact incidents are not happening now, wont mean it wont start happening eventually.

I ship on friday if im not on call for the weekend.

At my previous job we didn't have a QA team and we deployed continuously every day, including on Fridays, even though we were on-call. We just had a robust and reliable integration test suite, and we took code review very seriously. I've never been called on a week-end because of something broken specifically because of a Friday deployment.

If you're not confident about deploying on a Friday, you shouldn't be confident deploying at all.

To be clear, for big, risky changes, we obviously waited for the following Monday. The key is we didn't have a blanket ban on Friday deployments. Not being able to deploy for 20% of the working week is bad.

I am actually confident that each deploy runs a risk of implementing new bugs. I'm confident enough to do the deploy and our tests make it likely that most major functions are working correctly. But we have bugs, we continuously have bugs. And 9/10 times new found bugs are from new changes. I'd rather have those bugs be found when people are in office than needing to force the oncall back to work or have our product broken for the weekend.

If you are so confident why even have an oncall? Because we know reality is. Bugs are rare and severe bugs are more rare. But they do happen. So let's try to make them happen less when people are out of office.

Shipping things during the week is bad, if that's when your customers are online and most likely to make purchases, and you don't trust your processes. This whole post and thread needs a big ol "it depends".

>Why hire any QA? Why code review at all?

Are you upper management at my job?

Reply on news.ycombinator.com