I have moved to Portland, OR in USA recently. I’ve been busy; adjusting to new environment, settling in, and getting hands on with the iOS app being developed at my new job.
The app’s a protoduction. A rapidly developed prototype, with extensive year of development with the help of various unlike minded contractors, that now happens to be in production. The code isn’t a legacy code of course but it’s so brittle, coupled and hacked around with that I came to pulling my hair several times. Perhaps I did pull quite a few.
But that’s not the most interesting part of my job.
Working with bad code can be challenging but it can be refactored at some point. Legacy code can be rewritten given enough time. Working with a legacy engineer, however, is entirely another story.
Every single idea that you’ve held onto, no matter how simple that is, is challenged to its roots. Whether you understand SRP, Law of Demeter, loose coupling with interface, composition vs inheritance or even separation of concerns, you’ll be challenged to its benefits, use cases and comparisons to when not following them.
Even the most basic of the ideas that I came to believe in just because they felt intuitive, had to be explained to a point where I never bothered to understand. It makes for a fun conversation but not always.
Things get rough at two different levels. First, in team meetings where you are pushing for TDD or BDD, Higher Test Coverage, Automation Testing, continuous integration and deployment etc. You’ll have to face resistance to these ideas, new tools and technologies.
Second, when you have to work on a feature together. Every new method you’ll write will need to be explained why it couldn’t have been done inline, every dependency you’d inject needs to be explained, every responsibility that you craft out into a separate class would be challenged as unnecessary and CoreData will almost always be deemed as an overhead.
You’d have to explain every choice you make or approach you take. But that’s okay, because you read all about it right?
Well, not that easy. It can become increasingly difficult and intense at times, and you won’t be able to explain everything in a way that’d be good enough for them. Sometimes, stubbornness gets in the way as they are unwilling to get out of their 90s shell and sometimes you realized you just accepted that practice because that’s all you saw people doing and nobody ever questioned. But very few times, they just might accept.
The only way I’ve found to cope with such situations, is to think more carefully and deeply about my design choices. I read more about the practices that I am unable to convey clearly. This helps me get a better understanding of my design and not only helps me convince them but also helps in making more logical design choices next time boosting my confidence.
Although many of my such encounters happen to be annoying (cuz I assume people coding for so many years should just know about them), these interactions have been quite insightful.
Just like there have been books on ‘Working with Legacy Code’, there should be books on working with Legacy Engineers. Will you write one?