Selecting a JavaScript Framework? Start With the Business Considerations

The number of available JavaScript frameworks and libraries seems to increase almost daily. Each promises to address the most pressing issues facing developers in building the highly engaging and complex user interfaces demanded by today’s users. It can be a bit overwhelming. In this article, we present a methodical approach to selecting the best-fit javascript framework for your organization.

What’s Wrong With the Selection Process?

There is a natural desire for developers to use the latest technologies, with a temptation to select the framework or library de jour for each new development.

But despite what appears to be a purely technical consideration, selecting a JavaScript framework or library can have a significant business impact.  That is because selecting a new technology for a project can have very real implications to both your project and ultimately, the bottom line by:

  • Introducing greater risk
  • Increasing implementation time and costs
  • Producing ongoing maintenance issues for the life of the application

Too often the selection of the underlying technology for a project is, at best, a line item on a Gantt chart; once completed, it’s never revisited in the planning process. As a result, most project plans do not contemplate technology selection in a strategic sense.

Instead of leaving it to the developers to simply “pick one,” let’s explore a more methodical approach, beginning with the non-technical considerations.

Pinning Down the Non-Technical(Business) Considerations

A measured approach for selecting a JavaScript platform begins with a set of non-technical considerations. The current and future business requirements (translated into a set of user interactions, or visual design) fully define the system that the technology must address, and provide critical context by answering the “What,” “When,” “How,” and “Who” that drive an informed selection of a framework.

process-steps

What

Before the task of selecting technologies begins, the current and known future requirements of the application or system must be as fully defined as possible. The end purpose of the technology is to support current and foreseeable requirements so the less complete the requirements are, the higher the risk in selecting a platform.

Just as the requirements define “What” an application must do, they also define any other systems, computer or otherwise, with which the application must interact. While there is no consideration of the technical “How” in the requirements, the “What” is the true driving force for implementation. Anything that the application does not require now, or in the foreseeable future, is not a consideration.

When

Another non-technical consideration is the timeframe in which a project must be delivered. Timeframes are driven by economics, client demand, and a variety of other factors.

When impacts the selection of frameworks and libraries in ways that are not always knowable. Selecting a new technology must consider, at best, any new training that might be required or, at a minimum, the inevitable learning curve.

No matter how much individual developers have informally used a technology, initial progress will be relatively slower when cast in the context of a formal team-based development effort (with actual complex implementation demands).

How

The non-technical “How” is defined by User Experience and Visual Design teams. That’s because the interaction paradigms define not only outline how the users will interact, but also a finer definition of “What” the implementation must deliver. Not only is workflow realized by User Experience and Visual Design but also interactions and detailed presentations such as tables/grids, calendars and other smart controls such as auto-complete input fields are defined here. This is the “fine grain” definition of “What” the ultimate technology must support. As with the business requirements, anything that the visual design does not require now (or in the foreseeable future) is simply not a consideration.

Who

For any large development effort there is always the possibility that new staff may be required either full time or on a contract/contingent basis. The cost and availability of developers who are familiar with any new technology must be considered along side of the training of existing staff. The question of depth of experience is always a challenge for untried frameworks. These are direct cost/risk business concerns.

In addition to staffing the current effort, there is the somewhat hazy issue of retention and recruitment of future staff. While it should not be the overriding consideration for platform selection, not implementing new technology can make working on an application an unattractive option for current and future developers. Conversely, once developers have gained marketable experience with a highly in-demand framework or library, retention is always a concern as financial reward for a developer increases.

Summing It Up: It’s all About Business

In the end, selecting technologies should be considered a business decision. Too often the project owners are non-technical and treat this process as a black box owned by the technologists. But just like any other business decision, when it comes to approving the use of any new technology, project owners should always engage the development team in a risk/reward conversation and consider that either requirements or technology decisions must be revisited until risk and reward are in balance. By working through the What, When, How, and Who you can ensure that you are performing the right level of analysis to make the optimal choices for both your business and technology teams.

The number of available JavaScript frameworks and libraries seems to increase almost daily. Each promises to address the most pressing issues facing developers in building the highly engaging and complex user interfaces demanded by today’s users. It can be a bit overwhelming. In this article, we present a methodical approach to selecting the best-fit javascript framework for your organization.

By Dean Jennings

What’s Wrong With the Selection Process?

There is a natural desire for developers to use the latest technologies, with a temptation to select the framework or library de jour for each new development.

But despite what appears to be a purely technical consideration, selecting a JavaScript framework or library can have a significant business impact.  That is because selecting a new technology for a project can have very real implications to both your project and ultimately, the bottom line by:

  • Introducing greater risk
  • Increasing implementation time and costs
  • Producing ongoing maintenance issues for the life of the application

Too often the selection of the underlying technology for a project is, at best, a line item on a Gantt chart; once completed, it’s never revisited in the planning process. As a result, most project plans do not contemplate technology selection in a strategic sense.

Instead of leaving it to the developers to simply “pick one,” let’s explore a more methodical approach, beginning with the non-technical considerations.

Pinning Down the Non-Technical(Business) Considerations

A measured approach for selecting a JavaScript platform begins with a set of non-technical considerations. The current and future business requirements (translated into a set of user interactions, or visual design) fully define the system that the technology must address, and provide critical context by answering the “What,” “When,” “How,” and “Who” that drive an informed selection of a framework.

process-steps

What

Before the task of selecting technologies begins, the current and known future requirements of the application or system must be as fully defined as possible. The end purpose of the technology is to support current and foreseeable requirements so the less complete the requirements are, the higher the risk in selecting a platform.

Just as the requirements define “What” an application must do, they also define any other systems, computer or otherwise, with which the application must interact. While there is no consideration of the technical “How” in the requirements, the “What” is the true driving force for implementation. Anything that the application does not require now, or in the foreseeable future, is not a consideration.

When

Another non-technical consideration is the timeframe in which a project must be delivered. Timeframes are driven by economics, client demand, and a variety of other factors.

When impacts the selection of frameworks and libraries in ways that are not always knowable. Selecting a new technology must consider, at best, any new training that might be required or, at a minimum, the inevitable learning curve.

No matter how much individual developers have informally used a technology, initial progress will be relatively slower when cast in the context of a formal team-based development effort (with actual complex implementation demands).

How

The non-technical “How” is defined by User Experience and Visual Design teams. That’s because the interaction paradigms define not only outline how the users will interact, but also a finer definition of “What” the implementation must deliver. Not only is workflow realized by User Experience and Visual Design but also interactions and detailed presentations such as tables/grids, calendars and other smart controls such as auto-complete input fields are defined here. This is the “fine grain” definition of “What” the ultimate technology must support. As with the business requirements, anything that the visual design does not require now (or in the foreseeable future) is simply not a consideration.

Who

For any large development effort there is always the possibility that new staff may be required either full time or on a contract/contingent basis. The cost and availability of developers who are familiar with any new technology must be considered along side of the training of existing staff. The question of depth of experience is always a challenge for untried frameworks. These are direct cost/risk business concerns.

In addition to staffing the current effort, there is the somewhat hazy issue of retention and recruitment of future staff. While it should not be the overriding consideration for platform selection, not implementing new technology can make working on an application an unattractive option for current and future developers. Conversely, once developers have gained marketable experience with a highly in-demand framework or library, retention is always a concern as financial reward for a developer increases.

Summing It Up: It’s all About Business

In the end, selecting technologies should be considered a business decision. Too often the project owners are non-technical and treat this process as a black box owned by the technologists. But just like any other business decision, when it comes to approving the use of any new technology, project owners should always engage the development team in a risk/reward conversation and consider that either requirements or technology decisions must be revisited until risk and reward are in balance. By working through the What, When, How, and Who you can ensure that you are performing the right level of analysis to make the optimal choices for both your business and technology teams.

Interested in partnering with us?

Send a message and we will work with you to understand your needs.

Related Insights from Our Experts

2017-05-31T08:40:50+00:00