Scaling development
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 hang on to a talented crew, but we will nonetheless have to scale the process of acquiring new resources. How and when we hire JavaScript programmers is influenced by the features we're implementing, and the architecture we're putting together to to serve the functioning of those features.
From a day-to-day perspective, each team member should be responsible for implementing a specific chunk of our application. This is a complicated matter, and scaling influencers are to blame. We have to be careful about defining our roles for the team; to not make them overly restrictive. When things change in response to influencers, we need to pivot and deliver. Rigid role definitions don't help us much here. Conversely, we need to at least make an attempt to put boundaries in place, if there's going to be any level of autonomy in the way our components are developed.
Finally, we'll try to figure out if there's a sound approach to determine when we potentially have too many development resources. To say it out loud almost sounds like a bad thing. We've got all this talent, and all this work to do—it seems like those two items go hand-in-hand, do they not? No, not always.
Finding development resources
It's tempting, especially for product managers, to hire development resources not for what we're currently working on, but for what we've planned to work on in the future. But this doesn't scale well for a number of reasons. The first issue that new hires are likely to face in this scenario is not being able to learn the code by working on real features. Remember, they were hired to work on something on the roadmap that we haven't started yet. So they end up trying to be useful, but there's no real obligation for them yet. After a couple of weeks, they're fighting to stay out of the way of folks who are trying to wrap up work.
It's often better to consider what we're working on now. Is there a clear gap in our ability to deliver something that's expected in the next release of our software? If there is no well-defined gap, there's nothing for a new programmer to fill, and that just creates unnecessary communication overhead. The downside is that once we have clearly-defined gaps in our ability to develop the features we need, we won't be able to find the resources we need. This pressure can lead to hiring the wrong people, who don't gel with the team, for one reason or another.
A better approach to scaling the growth of our development resources is to wait till there's a gap. A gap doesn't necessary mean the world is on fire and you're going to fail as a company. It just means we could do things better, development-wise. We shouldn't try hiring more than one developer at a time if we can avoid it. If we take the time needed to find the right resource, then they're likely to fill any gaps we've identified with our process and some.
Tip
The quintessential resource on communication overhead during the software development lifecycle is "The Mythical Man-Month", by Fred Brooks.
Development responsibilities
The web browser platform is a complex space, with lots of technologies, and lots of moving parts. Some components of the web platform are more greenfield than others, but important nonetheless for us to understand. These emerging technologies are the future of the web. So who on our team is going to take ownership of learning these new technologies and socializing them throughout the organization? The challenge with the web platform is that there's more to master than one person can reasonably manage while simultaneously delivering product features. This is why we need at least some level of development roles.
How strict the boundaries are for these roles is dependent on the organization and the culture therein. The nature of the application under development will likely influence the types of development roles to setup too. There's no recipe, and strictness should be avoided where possible. The reason being that we need to adapt to changes brought on by scaling influencers. Strict roles essentially impede an otherwise capable developer from putting out fires. We generally don't have time for role boundary disputes as deadlines loom.
It's the architect of the front-end that's most likely to see the roles that make sense for implementing a given application architecture. And these are likely transient roles, guided by the architect but formed organically by the members themselves. This is especially observable in open source projects where people do what they're good at, and hence what they enjoy doing. While we can't always adopt this model exactly, we can certainly take cues from it—shape roles around what people are good at doing in the context of our feature requirements. Doing so will help developers get mentorship where they need it. Being interested in some aspect of JavaScript development doesn't mean they're proficient at the level they need to be. That's where having a senior person show them the ropes, doing something they like doing, has enormous payoffs for the product in the long term.
Too many resources
We've partially addressed the notion that it's easy to hire too many development resources— tempting even. When there's a clear roadmap ahead of us defined by product management, we want to take comfort in knowing we do in fact have the development resources to fulfill our roadmap. Hiring people too fast inevitably leads to too many development resources. We may already be there now, and the question then becomes what to do about it.
If we're unhappy with members of our team, and it's clear that we have more resources than are needed, the answer is straightforward. However, there's another way to look at things, if we have too many good resources we don't want to lose. We have to adjust the product roadmap to accommodate the development talent we've recruited. This often means finding a channel in which we're able to flow product ideas up from development to product management. This is more of an art than a science.
It's a challenging job, being a front-end architect and figuring out who's going to build what. The best way to scale our development resources is to provide an accurate map of our architecture to those that are currently implementing it. If there's discrepancies, figure out the right path forward. For example, there could be gaps and we need more JavaScript programmers, or there could be too many resources and something needs to change in the product.
Scaling development example
Our application has been around for a while, has seen some success, and is deployed in a variety of contexts. One of our core developers, Ryan, touches many areas of the code. He helps many other developers improve their code, providing suggestions and so on. Our application has reached the point where it's large enough 'for us to start noticing performance degradation across all features.
We need Ryan to implement some performance enhancements, which will involve re-factoring certain sections of code, and basically occupy all his time. We still have features to deliver, if we plan on scaling to meet customer demand. On the other hand, we're seeing red flags with our ability to scale performance-wise.
We realize that we need to hire a new developer to help with new feature development. This developer doesn't need Ryan-like chops. They need to have the basics down for the technologies we're using. If we're lucky, we'll find someone that grows into filling more responsibilities. But for now, the gap left by Ryan that we need to fill is fairly narrow. And to scale, we don't need to find another Ryan right away.