In your codebase, there’s something lurking under the surface. It’s prevalent and everywhere and you may not even realize it, despite interacting with it on a daily basis. They shape the structure of your project and guide it on its way to its final destination. Luckily, the presence of these mysterious beings supports your team on its journey. In cases where they’re not there, their absence is felt and usually forecasts trouble on the horizon.

If you guessed conventions, you’re correct. Throughout our codebases, we put up written or unwritten guardrails that provide support for our projects on their journey to completion. Conventions, rules, patterns, contributing guidelines – these are all examples of how we draw arbitrary lines in the sand about how to tackle routine issues as our projects progress.

I use the word arbitrary here lovingly. The beauty of software development – and most collaborative work, for that matter – is the ability to approach a particular problem from so many angles. But if you’re coming up against the same problem multiple times, it’s important to have a consistent solution to avoid reinventing the wheel each time. It doesn’t matter what path you decide to take, only that there is a reason behind that decision and you can apply that logic to similar situations in the future.

“If you’re coming up against the same problem multiple times, it’s important to have a consistent solution to avoid reinventing the wheel each time”

What Do You Mean I Have Conventions in My Project That I Don’t Know About?

Conventions often arise organically without the need to explicitly define them. As your project gets off the ground, it’s a good idea to periodically step back and reflect on what patterns you can glean from the work you’ve done. See if you can identify some core rules while your project is in its infancy so that you can apply to similar situations as the scope expands. Investments that you make in this arena early on will result in dividends and smoother workflows later on when there are more moving pieces hanging around.

Doing this early on has obvious benefits.

1. It can highlight areas where similar problems were solved in different ways. Taking note of these early can prevent your project from going the ways of the wild west. Were these different approaches necessary? Is one solution better than another? Why or why not?
2. It can force you to explain the logic behind decisions. This makes me think of the old adage “You don’t truly understand something until you can teach it to someone else”. Forcing yourself to articulate your logic and come up with supporting arguments can help you understand the problem at hand better and better prepares you for challenges to your approach in the future.
3. Provides a baseline for comparison. The scientific method is a thing for a reason. Knowledge is often discovered when our assumptions are pushed to their limits, but you need those assumptions to exist to begin with in order to explore new ideas.

The Twos Sides of the Coin

Like everything, there are upsides and downsides to all of this. I want to point out some of the common complaints related to relying on conventions too much

1.  Decreased creativity. If your team applies a cookie-cutter solution each time a particular problem arises, they could get tunnel vision. If there’s a fundamental flaw in your approach that is never questioned until everything blows up, it could necessitate a major refactor to correct all instances. Looking at a particular problem with fresh eyes each time allows for more space for innovation.
2. Accrual of technical debt. It’s easy to fall into a habit of “we do it this way because this is how we’ve always done it”, and bloat can easily catch a ride on the coattails of that line of thinking.
3. Rigidity. Software development projects need to be nimble and flexible in order to meet unanticipated issues. Having too many guardrails around development can impede a developer’s ability to address these challenges in an efficient manner
4. Misallocation of priorities. Once conventions are firmly established, some amount of effort is going to be required to make sure they’re being followed. A result of this can be the team spending too much time focusing on ensuring new features fall within these guidelines rather than focusing on the quality of the new work.

Despite the cons listed above, the scale seems to be tipped in favor of the benefits and that you can even use some of these supposed downsides to your advantage.

1. Efficiency. Having a tried and tested approach can allow your team to crank out routine features quickly and confidently.
2. Reliability. Having a test suite that covers the foundational concepts of a pattern can allow you to leverage that instead of testing every detail in each instance
3. Troubleshooting. If you move to implement a common paradigm for a new feature and it doesn’t work, it is usually easier to get to the root cause because the expected behavior is so well defined.
4. Maintainability. When developing features to solve a problem today, it’s probably a good idea to ask what the experience of someone five years in the future maintaining this code will be. Applying an approach seen throughout the codebase will help future developers wrap their head around an issue more quickly. This point also applies to onboarding new team members – the process can go much more smoothly when there’s trusted solutions to point to.

Flexibility > Perfection

“It’s okay to not have a plan that accounts for every detail; having a plan at all is the most important thing”

I have a saying that my coworkers have heard me use more than a handful of times. It’s a mantra that my father drilled into me as I was growing up, and it is something I have internalized in adulthood. “Execute a mediocre plan violently”. Mediocre is a word that I also use lovingly here. I am a firm believer in the idea that perfect is the enemy of good. The sentiment of my mantra is that it’s okay to not have a plan that accounts for every detail; having a plan at all is the most important thing. It gives you a foundation to build off of. It gives you a baseline to compare results to and adjust where needed. And that’s exactly how I view conventions – a reproducible approach to a common problem.

Using this philosophy, I think you can use some of the alleged downsides to your advantage. The idea that conventions stifle creativity or make software development too rigid are looking at the concept from a flawed perspective. If you find yourself forcing a problem to be solved by an established pattern instead of looking for an existing technique to solve your problem, it may be time to take a step back and attempt to identify if there are shortcomings somewhere along the line. Have confidence in your ideas, but be open to alternative solutions if something better suited comes to light.

Follow the Rules, and You’ll Get a Cookie

I reference codebases a lot through this post, but that’s just one example of where the utility of conventions is apparent. The truth is that any project based work can benefit from guidelines in the same way. Having clear procedures for common tasks avoids confusion, miscommunication, and mistakes. Don’t be lulled into thinking that these things don’t matter – it only takes one experience with trying to get a team to reach the same goal, with each individual handling things in their own distinct way, to make you want to pull your hair out.

Knowing that you can trust that the work done by your colleagues is absolutely critical in collaborative work. Having processes in place to make the work repeatable and consistent across the project, no matter which team member is performing the task, makes life much more pleasant and the journey much more enjoyable. Getting a project over the finish line successfully and efficiently is no easy task, but we strive to do so everyday here at Simple Thread. Have a project or problem that could use some advice? Let’s schedule a time to talk about how we can help with the solution.