Section 1.1: Project Maintainability

Assessing the maintainability of a project can be quite contentious, as comparing the maintainability of two distinct projects is fraught with challenges. Some developers find frameworks to be incredibly useful, while others view them as a source of frustration. This discrepancy has led to the belief that navigating frameworks is an inherent part of the development experience, complicating any objective evaluation of their impact on maintainability.

To gain a clearer understanding, we can refer to the research presented in the book "Accelerate: The Science of Lean Software and DevOps," which investigates the characteristics of high-performing versus low-performing teams. One critical takeaway is the importance of a loosely coupled architecture.

When leading teams, a common question I encounter is, "How can we determine if our architecture is loosely coupled?" A straightforward approach is to ensure that the components of your application can be easily replaced or removed. If components are difficult to detach, your application likely suffers from tight coupling, which can lead to a cascading series of issues.

Why is a loosely coupled architecture essential? We must acknowledge our fallibility; even after thorough research, mistakes happen. If you've chosen an unsuitable library or framework, it should be easy to swap it out without needing to overhaul the entire project. Focusing on long-term benefits rather than just the immediate gains of using a framework can save time and effort in the future.

Consider a scenario where you want to completely eliminate a framework: would that require extensive code rewrites? Can the application function independently across various services? If not, you may find yourself in a challenging position trying to separate the framework from the core logic, potentially undermining the initial time savings the framework promised.

Section 1.2: An Alternative Approach—Building Without a Framework

You might believe that constructing a service without a framework is time-consuming, particularly if you're accustomed to other programming languages. I can relate; I felt the same way when I first started programming in Go. However, forgoing a framework doesn't mean you must create everything from scratch—numerous reliable libraries are available to provide the necessary functionality.

This approach requires a bit more effort in research, which you're already engaging in by reading this article! A few hours of research is negligible compared to the overall project timeline. The flexibility gained through this effort will quickly compensate for the time invested.

So, if you choose to forgo a framework, how do you proceed with building a service? Initially, you might find it easiest to consolidate everything into a single file. This allows you to start quickly, postpone some decisions, and progressively evolve your project.

For reference, consider the example project I showcased during my talk "Let's Build an Event-Driven Application in 15 Minutes with Watermill" at GoRemoteFest—available at github.com/roblaszczak/goremotefest-livecoding. This project only requires two external libraries to function.

Feel free to adapt this code library as needed. While it may not encompass all the libraries your project requires, we have compiled an article detailing various Go libraries suitable for service development. We've utilized these libraries for several years and shared insights on how to evaluate their quality.

Section 1.3: The Importance of Thoughtful Decision-Making

Choosing how to develop a service is not a decision to take lightly. In the long run, making an ill-informed choice can severely impact your timeline and team morale.

After a poor decision, it's easy to fall into the sunk cost fallacy. Instead of striving to remedy the issues you've created, it's wiser to avoid these pitfalls altogether.