Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> But following that reasoning, why not also avoid shipping after 4PM?

Yes, exactly! Don't ship after 4 PM either!



I think what’s missing the most is context. I work on infrastructure and we never ship after 4 or on weekends because we have to support so many different kinds of behavior, and if we break any of those behaviors (which may very well be relying on undefined behavior/non-compliant protocol implementations) we are breaking our customers.

For people who work on applications they are often only hurting themselves if things break, so the risk profile is different. Maybe you don’t even have any customers, maybe your customers are consumers who are just not able to place orders.

IMO these groups often talk past each other (although as someone who works on infrastructure I think we often consider application developers’ more than they consider us, because they are our customers, and to them we are doing best when they don’t need to think about us) which leads to all these arguments from “Ship fast ship often - nobody uses our mostly static website which is easy to test, so who gives a fuck if it breaks” to “canary every change and carefully A/B test it with long release times to ensure it is safe”.


You know, that's a very good point. These arguments never bring up what's being built, what's the cost of things going wrong, etc. If you're running a Very Serious service with well-defined SLAs with a bunch of formal definitions and a suspicious number of 9s, your risk tolerance is entirely different from a startup with six highly caffeinated people who have naught but a dream and a three month financial runway before they're all out of a job. If devs from those two teams describe their release process to each other and don't mention what they do, they'll each probably conclude that the other is insane. One will vomit upon hearing the other describe a multi-week deployment scheme, and the other will vomit upon hearing the phrase "test in prod" said non-ironically.


I think if you're afraid to ship after 4pm, then you should write better code and/or test it better. There are things I'm afraid to do late (say upgrading 3rd party software), but shipping a new version of my software? Don't see why not.


> I think if you're afraid to ship after 4pm, then you should write better code and/or test it better. There are things I'm afraid to do late (say upgrading 3rd party software), but shipping a new version of my software? Don't see why not.

Your wording seems to indicate that you work by yourself. That's fine, but things change when large teams and systems are involved. You can't vouch for every single change or the inter-dependencies between all systems.

It's pretty elitist too. "Your code only breaks because you suck" doesn't make for good software engineering practices. Everyone makes mistakes.


That's why he wrote "test it better", it's intrinsic in that statement that he's well aware of the fallibility of humans


No, I don't work by myself. We are just good at writing tests and have a good QA team that writes good e2e tests.


Really depends on what you’re working on. Less complex things that are easily tested, sure. For more complex things that are hard to fully test, bad idea.

If you have a micro service that takes requests over / foo and /bar and returns JSON that needs to fit certain properties, and you’re submitting a change to fix a corner case bug or add a new property that isn’t read, sure.

If you are working on low level networking infrastructure that is used in tandem with thousands of different workloads you need to support, won’t work.


This is just faulty reasoning. Test as much or as well as you want, a deploy is always going to be a risk.

Eventually, your totally avoidable gamble will backfire.


I can actually see the narcissism emanating from this post. Try shipping code built by 4 - 6 teams each with 4 - 6 devs. See if something slips through.


I don't want to be the oncall in your team


Your loss. I haven't gotten PagerDuty ping in a year.

You know where I did get pings all the time? In companies that had strict release windows and would never deploy on Friday. Which in result motivated people to "push now & hotfix later" to meat the release cutoff date.


Doesn't make any sense if you want your workplace to have work/life balance. Ship on Monday, your customers will get used to it. That's what we do and it's fine, we don't ship on Fridays and it works out great.


Right, just write perfect code!

Things can and do break. It's impossible to test everything. That's why.


Yes, only ship code to production every other Tuesday from 10:30-10:30am.


I worked somewhere that did that and it was great. Everyone knew when the release was. If your code didn't make it into this one, well, no worries, it can go out in two weeks' time. And if something broke we had all day / all week to fix it.


sounds awful for feature velocity


Not all industries care about that, versus having fewer outages.


Some folks just cannot be satisfied with a warning and have to stick the fork in the outlet for themselves.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: