What is the best development framework?

Answer key questions together as a team

Credit: chuttersnap

Are you involved in a decision-making process of choosing a framework for your next development project?

Do you need to convince your co-worker to use a particular framework or avoid it altogether?

Choosing a development framework can be as simple as someone with authority in your organization picking one, or it can be as complicated as coming to an agreement within your opinionated team.

In the latter case where you have a say in the decision, this post will give you some insights on how to go about evaluating development frameworks out there.

Why do you need a framework?

The discussion of choosing any framework should begin with a question:

Why do we even need a framework in the first place?

This question seems like a no-brainer for pragmatic thinkers: it provides a standard set of tools with documentation maintained by third-party often at no cost.

Most developers in the job markets embrace one or more frameworks specific to their programming language of choice.

Employers are also aware of specific frameworks that they are in need for the project, and exploit experience and knowledge candidates will bring from their previous work.

At the end of the day, it saves money and time overall.

So it may not even justify building applications without involving a framework regardless of how small or big it is.

But the question remains relevant to share understandings of what exactly your team is trying to get out of a chosen framework.

Which framework is the right one?

For any programming languages with decent community size, there are usually few competing frameworks that often divide developers into different camps.

Let’s take a look at key characteristics of typical frameworks available in many programming languages.

Small Footprint vs. Enterprise Ready

One differentiating factor is the number of building blocks integrated into a framework.

Some frameworks are designed to be minimal, pluggable, and less opinionated.

These minimalist frameworks give developers enough lifting to save time from low-level operations but still provides a lot of freedom to build the rest.

Other types of frameworks bundle frequently used modules together for building enterprise apps.

The basic premise is that you will save time by starting with a framework that has all everything you will add anyway.

Key questions to ask your team

  • Can the team afford the time to evaluate and pick each building piece together?
  • Are majority of the team members already expert in one of the frameworks?
  • Does the framework comes with too much or too little features?

Popularity vs Preference

Another differentiating factor is the popularity of frameworks.

While popularity does not equal better framework architecture, it typically comes with a larger ecosystem of libraries, tutorials, and communities around it.

It is far easy and often inexpensive to hire additional developers for a popular framework than obscure frameworks that have low adoption rate.

Something to be aware is the duration of developers who stay on the project for a long haul.

Over the life cycle of any given software, it is common for the original software architect to leave the project, and newer developers with different taste will inherit the project.

So if the decision was made heavily based on original members’ preference alone, anybody who takes over the project could suffer from the decision.

Key questions to ask your team

  • How long are we going to stick around for this project?
  • Do we have room for creating a custom solution if necessary?
  • Can we still build a robust system with a chosen framework even if future developers don’t like the framework?

Maturity vs. Growth

Last significant differentiating factor for frameworks is its maturity and growth.

A framework that’s mature is more stable and less likely to introduce breaking changes to ensure backward compatibility.

It is especially a safe choice when starting a new project with constant scope changes

In contrast, new and growing frameworks often provide new development design patterns that solve pitfalls found in old frameworks.

However, not many developers are aware of the limitations with a cutting-edge framework and it could hurt you back in a long-run.

The worst case scenario is when cutting-edge frameworks get abandoned by the core contributors and you are left with no support.

If you only have a short amount of time or no time at all to experiment with the new framework, it might be a wise choice to stay safe with mature frameworks.

Key questions to ask your team

  • Do we understand what we are choosing to use?
  • Is the goal and scope of the project well defined at this point?
  • Is the mature framework nearly at the end of its life cycle?
  • Is the growing framework likely to survive in the future?

Answer key questions together as a team

When choosing a development framework, the team need to ask the right question and find a path that works for the current and future code maintainers.

If you tend to lean towards making a safe, proven approach, then open your eyes to something new and realize that there could be a better way.

If you tend to lean towards latest and greatest, balance your objective against business constraints and amount of risk the project can afford.

All in all, this is a first step to working together as a team that will pay off in a long run for your development team.

I’m a front-end developer lead at Fresh Consulting. I write about influential technical leadership (The Pragmatic Question) and latest technology experiments.

Follow me on Medium and Twitter