A large part of programming (probably the largest part) is refactoring. It’s the process of taking existing code and improving it. And part of that is determining when a class, feature, or even an application gets too big and splitting it up. It could mean applying the Single Responsibility Principle and splitting a class into 2 or more classes. Or moving features around in the UI so that the app is more organized.
Or even breaking a feature out into it’s own application. Facebook recently did just that when it split off the messaging portion of Facebook into it’s own application, the aptly named Messenger. They have received some flak for this, and from a user perspective it’s definitely not unwarranted. I have to download a new app? A second one? What happens to the old app? What if I’m browsing Facebook and I want to respond to a message? Now I have to switch apps? Are the permissions different on both apps? If I change my password do I have to re-login in both apps? Do I have to have the main Facebook app or can I only use messenger? It adds confusion, and one thing that isn’t good is confusing your users.
Mark Zuckerberg recently explained the reasoning behind the split himself:
… but if we wanted to focus on serving this [use case] well, we had to build a dedicated and focused experience. We build for the whole community. … We realize that we have a lot to earn in terms of trust and proving that this standalone messenger experience will be really good. We have some of our most talented people working on this.
Although people may be confused, what Facebook is trying to do is enhance the messaging user experience. People may not realize it now, but it was the right move, and especially from a programming perspective. They broke off Messenger so they could decrease the size of the teams working on both Messenger and the main Facebook application.
Quality vs Quantity
The quality of a product often goes down with the number of hands that touch it. The more programmers there are on a team, the more communication paths there are:
Many programmers know that as the size of teams grow, so does the time it takes to complete a feature. And things get forgotten. And Jerry said this but Ronnie said that. And you end up having 6 person code reviews.
And then there are the meetings. Oh god, the meetings. Let’s synchronously get together and talk about doing something instead of actually, you know, doing it.
Smaller teams are more focused. They’re leaner, meaner and can get things done faster. Leaner, meaner, more focused teams means a better overall product – both Messenger and Facebook itself. And a better overall product is, obviously, better for users.