Now we'll turn our attention to scaling the features we implement in our software. The users are the ultimate influence, and now that we have a rough idea of what's required in terms of scaling them, we can put this knowledge to work with feature development. When we think about scaling users, we're thinking about the why. Why do we choose this business model over that business model? Why do we need to enable things for one user role, and disable them for others? Once we get into actually designing and implementing the feature in JavaScript, we start thinking of the how. Not only are we concerned about correctness, but also scalability. As with users, influencers are the determinant when it comes to scalable features.

The last hurdle for us to overcome in terms of scaling influencers is that of actually developing the software. Any sufficiently complex JavaScript application isn't going to be written in isolation by just one developer. There's a team involved, even if it is only ad-hoc and self-organized in an open source context. In other institutions, teams and the roles within them are defined more concretely. Regardless of how the team is put together, scaling that team is a direct consequence of how we react to the other scaling influencers discussed so far in this chapter.

The first issue we'll address is the one we're most likely to run into first with a nascent software project—finding development resources. A team isn't a static thing; we'll have to add new resources as the software grows in code size and solution scope. Like it or not, the best resources are the most likely to leave as they're the most sought after. Ideally, we can...

We'll close out the chapter with a few checklists. These are simple questions for which there's no one correct answer. Some answers will remain the same throughout the lifetime of our software. For example, our business model will, hopefully, 'not change often. Others depend on the current state of things, and that's what these lists are for. We can come back to them again and again, anytime something changes. These could be requirements, users, new deployments, or changes to the development environment. These questions are nothing more than subtle reminders of the factors that influence scalable JavaScript applications. If reading them results in more questions than answers, then they've served their purpose.

There are three main areas of concern when it comes to scaling influencers in JavaScript applications. Each area influences the area directly beneath it, until we ultimately hit the ground floor, where development takes place.

First and foremost are the users of our software. There are a number of user-related factors that influence the need for our software to scale. For instance, the business model our organization chooses subtly affects later decisions about our architecture. License-based deployments are likely to be deployed on-premise somewhere, and therefore more likely to require customizations. The combinations of complexities are endless, and they all stem from the users of our software.

The next major area we looked at were the features themselves. We have to take much of the insight gained from thinking about our users and their influence on scale, and provide this as input to our feature design. For example, a lot may happen in a short period of time, once people start...