4 ms·

> But following that reasoning, why not also avoid shipping after 4PM? Yes, exactly! Don't ship after 4 PM either!

by CobrastanJorji 4y ago

fooster 4y ago
Yes, only ship code to production every other Tuesday from 10:30-10:30am.
- lmm 4y ago
  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.
  - throwaway98797 4y ago
    sounds awful for feature velocity
    - outworlder 4y ago
      Not all industries care about that, versus having fewer outages.
- forgetfreeman 4y ago
  Some folks just cannot be satisfied with a warning and have to stick the fork in the outlet for themselves.
0x457 4y ago
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.
- alar44 4y ago
  Right, just write perfect code! Things can and do break. It's impossible to test everything. That's why.
- outworlder 4y ago
  > 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.
  - 0x457 4y ago
    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.
  - lnxg33k1 4y ago
    That's why he wrote "test it better", it's intrinsic in that statement that he's well aware of the fallibility of humans
- opportune 4y ago
  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.
- mattmanser 4y ago
  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.
opportune 4y ago
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”.
- CobrastanJorji 4y ago
  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.

> But following that reasoning, why not also avoid shipping after 4PM? Yes, exactly! Don't ship after 4 PM either!

fooster 4y ago

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

lmm 4y ago
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.
- throwaway98797 4y ago
  sounds awful for feature velocity
  - outworlder 4y ago
    Not all industries care about that, versus having fewer outages.
forgetfreeman 4y ago
Some folks just cannot be satisfied with a warning and have to stick the fork in the outlet for themselves.

0x457 4y ago

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.

alar44 4y ago
Right, just write perfect code! Things can and do break. It's impossible to test everything. That's why.
outworlder 4y ago
> 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.
- 0x457 4y ago
  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.
- lnxg33k1 4y ago
  That's why he wrote "test it better", it's intrinsic in that statement that he's well aware of the fallibility of humans
opportune 4y ago
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.
mattmanser 4y ago
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.

opportune 4y ago

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”.

CobrastanJorji 4y ago
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.