Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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.




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

Search: