As a developer, there’s a tension between doing things consistently and knowing when to make change. Consistency generally means it’s easier to understand – there’s only one pattern for people to learn and then the next time they see something like it they have a pretty good guess at how it’s going to work.
People also generally learn by copying – and therein lies the problem for inexperienced developers. They look at what’s there, figure it’s better to follow the established pattern and then to add just one more thing. Generally it doesn’t really matter what it is – another branch to a if statement, another parameter to a method, another function to class, or another (ugh!) static call.
Responsible, experienced developers know where the inflection point is – where the right thing to do is to refactor the code, and to avoid adding just one more thing.
Good point. In the past, I’ve been on teams with inexperienced programmers and we’ve had this problem. Unfortunately, often our “solution” wasn’t to work with the inexperienced developers to help them understand that inflection point. Instead, we fell into the trap of trying to always factor the code up-front, which led to a lot of over-engineered code that never would have reached that inflection point anyway.