Very much yes. Behavioural flags are the worst kind of abstraction and a strong signal that the wrong abstraction was chosen.
The reality is that while abstraction is critical for keeping complexity under control, it is also hard. Refactoring common looking code will usually not lead to the correct abstraction.
As a recovering DRY addict, it is a lesson that took me a long time to learn.
edit: another common bad refactor/abstraction:
def fun1(...):
do_the_thing(...)
def fun2(...):
prepare_the_thing(...)
fun1(...)
def fun3(...):
prepare_a_bit_more(...)
fun2(...)
No other functions call fun1 and fun2. Often fun1 and fun2 are badly named because they are just steps in implementing the behaviour of fun3. Usually I inline back these cases as it greatly simplify understanding the code.
For people that want to have that style, I like to show them how to convert them into local functions if the language has that feature. At least that way they can't be accidentally misused (as easily... :)
The reality is that while abstraction is critical for keeping complexity under control, it is also hard. Refactoring common looking code will usually not lead to the correct abstraction.
As a recovering DRY addict, it is a lesson that took me a long time to learn.
edit: another common bad refactor/abstraction:
def fun1(...): do_the_thing(...)
def fun2(...): prepare_the_thing(...) fun1(...)
def fun3(...): prepare_a_bit_more(...) fun2(...)
No other functions call fun1 and fun2. Often fun1 and fun2 are badly named because they are just steps in implementing the behaviour of fun3. Usually I inline back these cases as it greatly simplify understanding the code.