[reallydontask]

I think a lot of people have seen that SOLID principles sometimes actually have the opposite effect of their intention, i.e. they make the code hard to reason about and thus less maintainable and harder to extend.

There are quite a lot of articles out there with valid criticism of SOLID, you might find that you don't disagree that much after all (or not). At the end of the day, blind adherence to dogma will likely result in negative effects.

If strict adherence to SOLID principles works for you, then great. Not been the case for me.

[Izkata]

> I think a lot of people have seen that SOLID principles sometimes actually have the opposite effect of their intention, i.e. they make the code hard to reason about and thus less maintainable and harder to extend.

For me, it's half that and half that the people most likely to promote it - like in this blog post - are doing it badly.

For example, their very first one, the Single Responsibility Principle, isn't. It's blind adherence to a code smell at the syntactic level, resulting in subclasses that are closer to god objects than single-responsibility.

IMO, extracting "Payments" into its own class/module is the "right" day to do it, whether or not the switch statement is kept or a method is created for each Employee type.