4 ms·

> You work in a SW team, and a peer who has many more years of experience than you is the lead for a particular project. He doesn't want you making branches for

> You work in a SW team, and a peer who has many more years of experience than you is the lead for a particular project. He doesn't want you making branches for different experiments, as "branches complicates things". Instead, there will be only one development branch and you have to make command line arguments with switches in the code for all the various experiments you need to do. It would not be my first choice, but committing on master and having feature flags can potentially be a good fit if you run tons of experiments. A company I used to work at did this and it ran very well.

BeetleB 5y ago
Some of the flags "interfere" with one another (i.e. are mutually exclusive). So you have to find all the relevant places in the code and put "if" branches. If you have 6 flags, you now have 2^6 = 64 different possible inputs to the program, and your code better handle it well. And these are all temporary. Once an experiment is over, you have to remove the flag and related if conditions. You certainly can design it well this way and abstract out the complexity, but that takes skill, and if the tech lead can't handle branches in version control, it's a good guess they won't be able to handle the abstraction needed to make it a good design either.
- mejutoco 5y ago
  I agree with you. I am not recommending it. It has all the problems you mentioned. I wanted to share that out there there are some decent companies doing this and it works for them / it does not need to be a red flag.
  - BeetleB 5y ago
    Yes, I too have experienced teams that compensate very well for poor SW practices, and even enjoyed some of them. I've even been in teams that didn't use version control and things worked out fine. But frankly, I'd rather not be in a team without version control, and I don't think many would fault me for discouraging others from joining such teams. There's a limited amount of time I have on this Earth, and the less time my brain spends on managing unnecessary complexity, the more time it has to do more useful things. I haven't found a team that's perfect, so there are always some compromises. I treat them as temporary compromises, though. Just because I put up with weird X behavior in a prior job and it worked out doesn't mean I should/would put up with it in future jobs.

BeetleB 5y ago

Some of the flags "interfere" with one another (i.e. are mutually exclusive). So you have to find all the relevant places in the code and put "if" branches. If you have 6 flags, you now have 2^6 = 64 different possible inputs to the program, and your code better handle it well. And these are all temporary. Once an experiment is over, you have to remove the flag and related if conditions. You certainly can design it well this way and abstract out the complexity, but that takes skill, and if the tech lead can't handle branches in version control, it's a good guess they won't be able to handle the abstraction needed to make it a good design either.

mejutoco 5y ago
I agree with you. I am not recommending it. It has all the problems you mentioned. I wanted to share that out there there are some decent companies doing this and it works for them / it does not need to be a red flag.
- BeetleB 5y ago
  Yes, I too have experienced teams that compensate very well for poor SW practices, and even enjoyed some of them. I've even been in teams that didn't use version control and things worked out fine. But frankly, I'd rather not be in a team without version control, and I don't think many would fault me for discouraging others from joining such teams. There's a limited amount of time I have on this Earth, and the less time my brain spends on managing unnecessary complexity, the more time it has to do more useful things. I haven't found a team that's perfect, so there are always some compromises. I treat them as temporary compromises, though. Just because I put up with weird X behavior in a prior job and it worked out doesn't mean I should/would put up with it in future jobs.