Old School Likes Things Hard — Live with It
Something I’ve come to realize after working with new and old school developers: younger, junior developers tend to propose improvements to the current design, and older, senior developers tend to reject them. You can probably easily picture someone with 20 years of experience saying, “Yeah, new people come in and think they can make better designs. They just don’t understand that things are the way they are for a reason.”
Likewise, when something new is to be created and someone proposes a simple, clean design, many old school developers might frown on that as well, and even argue for a more complicated, harder-to-understand design. This has long puzzled me, but I think I’ve finally come to a conclusion: hard is typically in their nature. These developers have often grown up in the software profession with convoluted designs and unreadable code as their bread and butter. “Hard” is what they consider normal; “simple” leads them out of their comfort zone.
Think about it. If you’ve spent years of your existence living in a reality where code rots, change is dangerous, and design ought to be complex, you’re naturally suspicious when someone comes in and says they can achieve the same objectives without all that fuss. If someone with less experience said they could do it much better, wouldn’t you be sceptical? Wouldn’t you assume that if they see it so simple it’s probably because they’re missing something?
Old school developers aren’t being difficult — they’re just being human.
If you’re in a similar situation and you want your team to succeed, the first thing you need to understand is that we are the product of our experiences. Very senior developers may appear to be a challenge when it comes to simple design — but their ability to manage complexity is priceless. They are the best at maintaining legacy code, they know where all the bodies are buried, and they can dance through code making just the necessary touches to fulfill the requirement, without breaking anything.
Be careful when creating new code, though. Some junior developers who pair with old-school types may actually come to adopt some of the life-needs-to-be-tough mindset. If you need to pair someone with the old-school developers, make sure they have experience and can understand complexity without accepting it. You want to find someone who can see the thing working, and then refactor to have a proper design.
Finally, do not try to change old-school developers by telling them to change. They are war veterans who have lived in the thick of it — none of your pretty arguments or popular articles is going to have much effect on them (other than upsetting them or inspiring their cynicism). I’m not saying old-school developers can’t be converted to new practices, but if such thing happens it will be out of showing, not telling, out of internal motivation, not external directives. Accepting them and living with them may not sound ideal, but will be more productive.
