3 ms·

> If it is possible for that other team to merge a broken build, you are doing it wrong. This assertion is unrealistic and fails to address the problem. The fa

> If it is possible for that other team to merge a broken build, you are doing it wrong. This assertion is unrealistic and fails to address the problem. The fact that builds can and do break is a very mundane fact of life. There are whole job classes dedicated to mitigate the problems caused by broken builds, and here you are accusing others of doing things wrong. You cannot hide this away by trying to shame software developers for doing things that software developers do. > Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code. That observation is so naive that casts doubt on whether you have any professional experience developing software. There are a myriad of ways any commit can break something that goes well beyond whether it compiles or not. Why do you think that companies, including FANGs, still hire small armies of QAs to manually verify if things still work once deployed? Is everyone around you doing things wrong, and you're the only beacon of hope? Unreal.

roguecoder 1y ago
I haven't seen a broken build in at least nine years, not since I left the company with a merge process built out of bash scripts that took three hours and required manual hand-holding. I am genuinely curious what situations you are seeing where builds are making it through CI and then don't compile. It isn't always worth investing in quality, but when it is it is entirely possible to write essentially bug-free software. I've gone seven months without a bug in production and the one we saw we had a signed letter from product saying "I am okay if this feature breaks, because I think writing the tests that can verify this integration was going to take too long." FAANG companies aren't prioritizing writing software well: they are prioritizing managing 50,000 engineers. Which is a much harder problem, but the management solutions that work for that preclude the techniques that let us write bug-free software. One of the great things about startups is that it is trivial to manage five engineers, so there is no reason we have to write software badly.
- JackSlateur 1y ago
  You are absolutely right. Of course, if people wrote bug-free code, then there would be no bug ! Bug-free code in the actual code, or bug-free code in the test code, this is the same story. If you write stuff and never have any bug, then either: - you are lying - you do not write much - you only write really simple things - you are Jesus, came back from heaven to shine his light on us, poor souls The more complicated, intricate stuff you have, the more bugs you'll get (and only time will allow you to fix that). Tests are great do define how you think it should work, and to ensure it keeps doing that way. Take the time to think about the third point on the bullet list above.
  - quesera 1y ago
    This seems a bit much. In the DVCS era, we have inexpensive branching. Do as thou wilt on your topic or epic branches. Rebase them against main/master before merging upwards. Fix what must be fixed first. Main/master branch should never fail CI. If it does, there is something seriously wrong with your branch lifecycle and/or deployment process.
    - MrJohz 1y ago
      Sure, but "never fails CI" is a different assertion from "has no bugs", or even "deploys correctly in production".
      - quesera 1y ago
        If you test defensively[0], CI will catch the vast majority of functional bugs. Anything that is missed suggests at least two bugs: one in tests, and one in business logic.[0] A reliable deployment pipeline is outside of CI, but can be kept straightforward and minimal to constrain the scope of failures. Bugs happen, and systems complexify. It is possible to manage both of those risks down to near-zero by the time code reaches production release candidate stage. In some industries, this is more important than others, though -- obviously the goal is to match quality to business needs. But I agree with our thread predecessor: I haven't seen a broken build make it anywhere near production in many years, and it's not because of the snarky dismissal that provoked my original response. [0] In some situations, proper tests are not possible, and in others they are not practical. And I acknowledge that I'm omitting things like visual design/layout bugs, which is probably not reasonable.
- motorest 1y ago
  > (...) it is entirely possible to write essentially bug-free software (...) You lost what little credibility you had left.

roguecoder 1y ago

I haven't seen a broken build in at least nine years, not since I left the company with a merge process built out of bash scripts that took three hours and required manual hand-holding. I am genuinely curious what situations you are seeing where builds are making it through CI and then don't compile. It isn't always worth investing in quality, but when it is it is entirely possible to write essentially bug-free software. I've gone seven months without a bug in production and the one we saw we had a signed letter from product saying "I am okay if this feature breaks, because I think writing the tests that can verify this integration was going to take too long." FAANG companies aren't prioritizing writing software well: they are prioritizing managing 50,000 engineers. Which is a much harder problem, but the management solutions that work for that preclude the techniques that let us write bug-free software. One of the great things about startups is that it is trivial to manage five engineers, so there is no reason we have to write software badly.

JackSlateur 1y ago
You are absolutely right. Of course, if people wrote bug-free code, then there would be no bug ! Bug-free code in the actual code, or bug-free code in the test code, this is the same story. If you write stuff and never have any bug, then either: - you are lying - you do not write much - you only write really simple things - you are Jesus, came back from heaven to shine his light on us, poor souls The more complicated, intricate stuff you have, the more bugs you'll get (and only time will allow you to fix that). Tests are great do define how you think it should work, and to ensure it keeps doing that way. Take the time to think about the third point on the bullet list above.
- quesera 1y ago
  This seems a bit much. In the DVCS era, we have inexpensive branching. Do as thou wilt on your topic or epic branches. Rebase them against main/master before merging upwards. Fix what must be fixed first. Main/master branch should never fail CI. If it does, there is something seriously wrong with your branch lifecycle and/or deployment process.
  - MrJohz 1y ago
    Sure, but "never fails CI" is a different assertion from "has no bugs", or even "deploys correctly in production".
    - quesera 1y ago
      If you test defensively[0], CI will catch the vast majority of functional bugs. Anything that is missed suggests at least two bugs: one in tests, and one in business logic.[0] A reliable deployment pipeline is outside of CI, but can be kept straightforward and minimal to constrain the scope of failures. Bugs happen, and systems complexify. It is possible to manage both of those risks down to near-zero by the time code reaches production release candidate stage. In some industries, this is more important than others, though -- obviously the goal is to match quality to business needs. But I agree with our thread predecessor: I haven't seen a broken build make it anywhere near production in many years, and it's not because of the snarky dismissal that provoked my original response. [0] In some situations, proper tests are not possible, and in others they are not practical. And I acknowledge that I'm omitting things like visual design/layout bugs, which is probably not reasonable.
motorest 1y ago
> (...) it is entirely possible to write essentially bug-free software (...) You lost what little credibility you had left.