Recently I listened to a talk given by an ex-ThoughtWorker, Simon Harris. One of the things that Simon talked about was how we, developers (and generally speaking – human beings) sometimes tend to reject what is unfamiliar to us. Within software development context it can be an existing/legacy application or a module that we need to extend, and which is difficult to understand.
Really, how many times we looked at someone else’s work (eg:. a developer that has left the company a long time ago) and thought “Dude, this is so weak … come one”?
Instead of just pointing fingers, maybe we should stop for a moment, try to think and understand, what were the reasons for producing that mediocre piece of code? Look at the current software’s state from a different angle. Sure, sometimes a poorly written software is simply just that – a poorly written software without a particular reason. But at other times, perhaps there were unknown variables in the equation that prevented developers produce something of a higher quality: technical limitations? Some internal politics? Tight deadlines? Environment?
Understanding the historical/current state of an application, can only help us to come up with better results in the long run. I really enjoyed Simon‘s talk, he clearly draws from his extensive experience.