2 ms·

It is indeed extreme and very limited to writing web applications in a specific context. That is not how I have been working for the past 20 years, and his solu

It is indeed extreme and very limited to writing web applications in a specific context. That is not how I have been working for the past 20 years, and his solution would be destructive in my daily job. One of his previous article (https://thinkinglabs.io/articles/2022/05/30/on-the-evilness-of-feature-branching-the-problems.html https://thinkinglabs.io/articles/2022/05/30/on-the-evilness-...) takes it one step further. It seems that everyone works on everything at once and people step on each other toes all the time. They would definitely improve by using the feature branches that they shun. Last but not least, he's talking about quality, high-trust, or on-demand build which are topics unrelated to a branching strategy. Quality is done with local tools like linters and CI to prevent bad merges, and on-demand build can be done with tags in any branching strategy. The whole article is confusing actually. > everyone is working on a single mainline It's the same for every strategy. And TBD mentions release branches, so... he's wrong in the very first sentence. I do like TBD though because it's a clean way to handle release and feature branches, but that's it.

JimDabell 1y ago
> It is indeed extreme and very limited to writing web applications in a specific context It’s not. I’ve used TBD for mobile apps and it’s been great. I do prefer short-lived branches with PRs (which is another form of TBD), but it’s wrong to say that their approach is limited to web apps in a specific context.
- Disposal8433 1y ago
  It definitely is. He's saying that "we uncover more problems sooner" which can only be done on systems such as web sites where the tests and their results are done very fast. Where I work we can have weeks of testing to make sure that every feature has not introduced a bug. I'm not criticizing TBD which I like, I criticize his thoughts that it's related to TBD where in reality the whole article talks about his specific job and the organization of his team, which again is unrelated to any branching strategy.
  - JimDabell 1y ago
    > It definitely is. So are you saying I just imagined using this for non-web projects? > He's saying that "we uncover more problems sooner" which can only be done on systems such as web sites where the tests and their results are done very fast. I don’t understand why you think this. Uncovering problems quickly is one of the major points of continuous integration and it’s in no way limited to the web. > Where I work we can have weeks of testing to make sure that every feature has not introduced a bug. This does not mean that branchless TBD is limited to the web, it means that it’s not suitable for your project.
    - Disposal8433 1y ago
      You misunderstood everything to the point I think you're doing it on purpose. I like TBD, but the article is NOT about TBD. > are you saying I just imagined I use TBD for everything and I like it. I was talking about the writer of the article, not you. The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy. His other articles confirm this.
      - JimDabell 1y ago
        You said it was limited to web projects, I said I had used it in non-web projects and it wasn’t limited to web projects, and you said “it definitely is”. How else am I meant to interpret that? You are directly saying that what I have personally experienced isn’t possible. > The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy. This does not resemble the article we are commenting on.

JimDabell 1y ago

> It is indeed extreme and very limited to writing web applications in a specific context It’s not. I’ve used TBD for mobile apps and it’s been great. I do prefer short-lived branches with PRs (which is another form of TBD), but it’s wrong to say that their approach is limited to web apps in a specific context.

Disposal8433 1y ago
It definitely is. He's saying that "we uncover more problems sooner" which can only be done on systems such as web sites where the tests and their results are done very fast. Where I work we can have weeks of testing to make sure that every feature has not introduced a bug. I'm not criticizing TBD which I like, I criticize his thoughts that it's related to TBD where in reality the whole article talks about his specific job and the organization of his team, which again is unrelated to any branching strategy.
- JimDabell 1y ago
  > It definitely is. So are you saying I just imagined using this for non-web projects? > He's saying that "we uncover more problems sooner" which can only be done on systems such as web sites where the tests and their results are done very fast. I don’t understand why you think this. Uncovering problems quickly is one of the major points of continuous integration and it’s in no way limited to the web. > Where I work we can have weeks of testing to make sure that every feature has not introduced a bug. This does not mean that branchless TBD is limited to the web, it means that it’s not suitable for your project.
  - Disposal8433 1y ago
    You misunderstood everything to the point I think you're doing it on purpose. I like TBD, but the article is NOT about TBD. > are you saying I just imagined I use TBD for everything and I like it. I was talking about the writer of the article, not you. The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy. His other articles confirm this.
    - JimDabell 1y ago
      You said it was limited to web projects, I said I had used it in non-web projects and it wasn’t limited to web projects, and you said “it definitely is”. How else am I meant to interpret that? You are directly saying that what I have personally experienced isn’t possible. > The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy. This does not resemble the article we are commenting on.