When you’re working on a piece of software for a long time, it can be easy to overlook poor architecture or an awkward UX. You may spend your day avoiding the dark corners of your app and choosing to forget that they even exist. Unfortunately, when this happens, the health of our codebase and application can suffer.
Recently, my project team gained a new member—a fresh set of eyes unfamiliar with our application’s design. This newness allowed them to notice inconsistencies and ask valuable questions about why we chose to architect our app as we had.
Design Subtleties (and Not-So-Subtleties)
We spent a portion of one afternoon in a “power hour,” taking time to step through the app and point out any obvious bugs or areas of improvement. While one of my existing teammates and I had a few items to add to the list, our new teammate had multiple notes on each screen of the app. In reviewing these notes, we realized they had marked down many issues that we had acknowledged (and forgotten about) months prior.
We were surprised that our teammate had come up with so many inconsistencies within the app, but on closer inspection, that surprise turned into realization. We had let so many of these issues fall to the wayside while we added features and crushed stories.
Forgotten (or Ignored) Dark Corners
Software architecture is crucial to making the codebase usable for developers. Every application has dark corners or code smells, ranging from well-hidden to very obvious. We leave abandoned TODOs littered around, hoping that one day, we’ll get the chance to refactor.
These pieces of code that we don’t want to remember writing but also want to fix every time we run into them can cause pain for both new and old team members. When you come across one while introducing a new teammate to the codebase, it can be almost embarrassing to admit your mistakes. Yes, you wrote it, and no, you’re not particularly proud of it. But moments like this can easily turn into perfect teach-and-learn opportunities, allowing you to refactor the code while giving your teammate a better sense of how systems should be architected.
Code Reviews (Why Are You Doing It That Way?)
Not only can a fresh pair of eyes provide insight into poor architecture, but they also force you to understand your code from a new perspective.
While pairing with a new teammate who was still learning the ins and outs of Objective-C, they would ask questions about syntax and why we chose one approach over another. When I looked over this code on my own, I would just tell myself, “Yes, this is the pattern. This is how it’s always been. I’m going to keep doing it this way.” I never took the time to really question the motivation behind architectural decisions that had existed for a long time.
So many of the software design decisions that had been made were made a long time ago, before other alternatives existed and long before I even joined the team. When new solutions to old problems came up, we would often find ourselves saying we’d work on it on a Friday at the end of a sprint when we’d have more free time. Getting a new perspective on these “Friday tasks” can be a wake-up call to reevaluate their value and push for better refactoring going forward.
But My Code Is Perfect!
While it can be a little jarring to have someone come in and question the months of work you’ve done, it’s worth remembering that they’re not doing this to spite you. They’re simply trying to formulate an understanding of the WHYs of the software.
This can provide a learning experience for your entire team. Getting a new perspective on old code and an old application can help spur necessary refactoring that will make using the app more enjoyable and make the experience of working on the app better.