Nicholas Zakas: The biggest challenge is making sure everyone is on the same page. In a lot of ways, you want the entire team to work as a single engineer, meaning that every engineer needs to be committed to doing things the same way. Code conventions are vitally important, as are code reviews, to make sure everyone understands not only their role but the roles of everyone else on the team. At any point in time, you want any engineer to be able to step in and pick up another engineer’s work without needing to figure out his or her personal style first.
How do you design an app that balances responsiveness and structure?
Nicholas Zakas: As they say, the first step in solving a problem is admitting you have one. The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don’t know everything, you begin to design the system defensively. You identify the key areas that may change, which often is very easy when you put a little bit of time into it. For instance, you should expect that any part of the app that communicates with another system will likely change, so you need to abstract that away. You should spend most of your time thinking about interfaces rather than implementations.
Do lessons applicable to large teams also apply to smaller teams?
Nicholas Zakas: Small teams still need to build scalable solutions because hopefully, one day, the team will grow larger. Your system should work for any number of engineers. The proof of a good design is being able to move seamlessly from five engineers to 10 and then more without needing to fundamentally change the design.
This interview was edited and condensed.
Associated photo on home and category pages: Scaffolding: Not just for construction workers anymore by kevindooley, on Flickr
- The secrets of Node’s success
- John Adams on Fixing Twitter: Improving the Performance and Scalability of the World’s Most Popular Micro-blogging Site