The conventional wisdom in software engineering advocates for breaking down code into loosely coupled functions, classes, and modules, among other things. Numerous books and blog posts discuss various approaches that help us achieve the best possible design for our code.
Sometimes, we may get lucky and find a design pattern that perfectly matches our business logic. However, there's a risk of making premature assumptions, which can result in our code being misaligned with the business problem.
I propose an alternate approach that may sound counterintuitive.
Start by writing messy code—-messy code that diverges from the traditional "clean" code, following design patterns, programming paradigms, or any opinionated design methodologies.
What do I mean by messy code here?
I begin by putting all my code in a single function (or method). This means disregarding principles like Separation of Concerns, Single Responsibility Principle, or even DRY (Don't Repeat Yourself).
Then, I write tests to verify that my code works.
At this point, I am technically ready to open a Pull Request, meaning somebody will need to read my code and review it. This is when I check my code for readability.
Based on my experience, having as much context available in one place makes code more readable. When I have a function with all the code in it, I have all the context I need to inform my design. If I feel the code is unreadable, I break the large function into meaningful blocks. On the contrary, figuring out the building blocks from scratch would take me much longer.
Having all the code in one place can be considered messy, but it is much more malleable than having code implemented in mismatched design pattern.
What about working with existing codebase?
An existing codebase may have predefined patterns. But that doesn't mean they should be unchangeable. As described above, these patterns may be a perfect fit. In that case we use them to inform the design of new features. But if they aren't, there is no reason why we should stick to them for all future code.
If all future implementation is dictated by initial design decisions, then it means that our software is hard to change. Software is supposed to be "soft" i.e. easy to change, and change is a good indicator of a healthy and successful software project.
How did I arrive here?
My fascination with architectural patterns and design methodologies began early in my career. Initially, I felt embarrassed by my code, which worked perfectly but lacked the elegance of a well-designed system. To address this, I immersed myself in studying design patterns, only to later realize that many of these patterns were primarily designed for Object-Oriented Programming. As I continued to develop my coding skills in Python, a more flexible language, I learned the importance of seeking design patterns native to Python.
Over time, I also encountered counterarguments such as WET (Write Everything Twice) versus DRY (Don't Repeat Yourself), which expanded my perspective on coding.
Given the abundance of strongly worded literature in the software industry, it is easy to become too fixated on the means of accomplishing our tasks and lose sight of our ultimate goals. Therefore, I find it valuable to approach coding from a first principles perspective—breaking down a problem into its fundamental elements and rebuilding a solution from those elements. Starting with messy code represents my personal approach to this philosophy, and I encourage you to find your unique path in coding as well.
If you liked reading this post, you can follow me on LinkedIn for more.