Get in touch
In this three-part blog series, we aim to introduce you to Flamingo, AOE’s modular, open-source framework based on Go, step by step. Perhaps you’ve already found some exciting insights in the first part about the Go programming language? If not, you can always go back and read it here. Today, in part two, we’ll dive into some interesting facts about the pros and cons of development frameworks in general, before focusing on Flamingo in part three, with lots of information on creating custom, fast, and flexible web applications.
Let’s jump into Part 2: Pros and Cons of Development Frameworks
Many believe that no qualified developer should ever use a framework to write code unless they are working in a completely unstructured environment. Whether the complexity of the development environment is genuinely high or just feels that way to the individual developer or team, the need for a structured approach amid a jungle of conflicting priorities, uncontrollable business domains, product groups, and third-party systems makes development frameworks very popular among developers.
The arguments for and against using development frameworks are well-documented and have been hotly debated for decades, with no consensus in sight. The most common arguments include:
Pros of Development Frameworks
Cons of Development Frameworks
After considering the pros and cons, it quickly becomes clear why the general debate over using frameworks has persisted for so long without a definitive outcome. There are indeed strong arguments both for and against their use. The very features and characteristics of a framework that bring clear benefits in some circumstances almost inevitably cause costs and disadvantages in others. Every framework inevitably involves a series of trade-offs between these pros and cons. The real question is whether the trade-offs that a particular framework brings offer significant benefits to an organization or not.
Delving into the idea that a framework represents a series of trade-offs between development priorities, we must ask: are these trade-offs good or bad? Unfortunately, this isn’t easy to determine, as opinions on what constitutes a good or bad trade-off often vary widely. Priorities can differ or even be contradictory at this point. This has significant implications for the decisions an organization must make when using a development framework. One aspect to consider is the differing priorities of developers and management. In a small, technically-oriented company where the leadership and management might themselves be developers, this contrast may not even exist. In large enterprises, however, the company’s priorities regarding overall organizational efficiency, various types of costs, long-term IT resources, sustainability, stability, and security are likely to conflict with the concerns of individual developers and product teams.
Yet, ignoring developers' concerns can also be a headache for management. There is always market demand for skilled developers, and in most companies, the shortage of talent, especially in development, is a key focus of leadership. Conventionally, frameworks are often seen as a powerful ally of the company in mitigating the risks of developer turnover: standardization through frameworks can help avoid idiosyncratic, hard-to-maintain code. This reduces a company's dependency on the original developers of an application and makes it easier for new developers to familiarize themselves with the existing codebase.
On the other hand, a 2022 Stack Overflow survey found that feeling unproductive at work was the most important factor (45%) for developer dissatisfaction —even more so than salary. Most developers are very particular about their development environment and toolchain, as they view these as vital to their productivity. The consequences of top-down imposition of a poorly fitting framework are thus evident. Another important factor regarding necessary trade-offs and differing priorities inherent in any development framework is the user base. The needs of a company with a small, autonomous development team differ significantly from those of a CIO selecting an enterprise framework for hundreds or thousands of developers and different product teams across various regions and business units. The framework that works for one is almost inevitably unsuitable for the other. Whether it’s an open-source or proprietary framework, it must be tailored to the needs of a defined and relatively homogeneous user group to ensure that the advantages clearly outweigh the disadvantages.
The importance of feedback and incorporating end-user needs is one of the main reasons for the growing dominance of open-source development systems. Development within an open community is based on collective agreements and productive compromises. Where communities place users at the center of project leadership and development, user feedback is immediate and inherent. Open-source development frameworks thus reflect their communities and their shared priorities. In most guides on choosing an open-source framework, a large and diverse project community is listed as a key criterion. For small organizations and individual developers looking to accelerate development in a particular programming language, this is almost certainly true, as larger communities are more stable and sustainable.
For users within a company, the size of the community also matters for sustainability, but other factors, such as the size and stability of individual users and the organization responsible for maintaining the systems, also contribute to sustainability and play other important roles. As mentioned earlier, the priorities that enterprise users place on a development framework often differ from those of smaller organizations and individual developers. In a large, diverse open-source community, the concerns of enterprises may sometimes be overlooked, and poor compromises become more likely. In many ways, development frameworks tailored to enterprises are better suited to communities focused on reflecting the decisions and priorities of enterprise users with similar needs and priorities.
To deepen this argument, we must circle back to our original summary of the pros and cons of frameworks in general. Take the example of standardized “structure”: more structure usually equates to a predominantly dogmatic framework. For a small organization or individual developer, this can lead to unnecessary frustration. Creativity and flexibility seem unnecessarily restricted, with no obvious benefit. A framework that already strongly enforces best practices is likely to have a steeper learning curve and may lead to more unnecessary dependencies and performance hits in small, standalone applications.
Now, let’s consider structure from an enterprise perspective. For IT management and executives trying to steer many different product development teams in a coherent direction, a form of consistency in development practices is essential. A framework can be an invaluable ally here in maintaining oversight, ensuring stability, managing developer turnover (as described above), and, perhaps most importantly, facilitating more effective collaboration between teams and boosting overall productivity.
And from the perspective of individual developers and teams? Any frustration over freedom and creativity being constrained by a prescribed framework is likely to be outweighed by other factors. Enterprise developers usually have to integrate more third-party systems that are beyond their control anyway—from other development teams, external services, and proprietary applications. In this scenario, a more restrictive framework acts as a kind of diplomat, reconciling the differing interests of the teams.
Our Conclusion: Choosing a new framework is not just a complex and challenging strategic decision; it involves a whole series of complex and challenging strategic decisions. Features that are ideally suited to the needs of enterprises can be too great a compromise for small units or individual users, leading to a general rejection of frameworks.
Did you enjoy our blog post on “Pros and Cons of Development Frameworks”? Then stay tuned for next week’s third part, “Introduction to Flamingo.” If you have any questions in the meantime, feel free to reach out to our AOE development team via this link.
