How viable is it to have a single webapp over several private small repositories?

Question

We are a low budget team working on a web app. Due some complications we might need to work remotely from January and onward. After some consulting and googling, we concluded that several small repositories is the cheaper option. We're thinking in:

• Backend and services

• Middleware

• Front End

This way we can separate in relevant teams, each one working remotely in their repository. How viable is it to have our app in several private small repositories?

Additionally what considerations should we take if we were to work this way?

Note: I'm asking about a single, big project divided over several small repositories. This differs from the related questions asked on this site, because they are asking for multiple projects in either one or several repositories. Additionally, we chose to dived the project, mostly because we aren't willing to invest a single big private repository unless we are going to stick with it.

Answer 1

"...we concluded that several small repositories is the cheaper option."

That's great. Divide and conquer. You break the effort into logical pieces, give each piece to a different hard-core team, work like mad for a few months, bring everything together, and...

and...

Well, it'll be a damn nightmare. It definitely won't be cheaper. Why would it be?

The largest "cost" in any software project is communication. You don't save money by writing code faster. That's the secret programmers won't admit. (Psst. Don't tell anyone. It really doesn't matter how fast you write code.) The time spent writing code is absolutely dwarfed by the time spent planning and talking and negotiating and fighting and talking and meeting and talking some more and compromising and realizing you shouldn't have compromised and promising to do better and yelling and wishing and "solutioning" (that's not a word, dammit) and looping back and pinging and talking and not being able to sleep.

So, you break your work into discrete chunks and hand each chunk off to a separate team. What did you just do? You added communication burden. If you're lucky and your teams are perfect, there's absolutely no cost difference between one big repository and a few small repos. If you're not lucky (few are), breaking into separate teams will actually cost more. It's hard enough to stay in synch when you're all in the same code base, stepping on each others' toes. Now imagine how hard it will be when three different teams think the requirements mean something slightly different (with no way to correct quickly because they're not breaking the other teams' stuff), have slightly different cultures, and, in the end, are very motivated to avoid blame when things go wrong so they're more than willing to throw the other teams under the bus.

I know, I know... your teams are better than that. But are they really? Are you confident enough to bet money on it?

Look, in either approach (big repo/many little repos) you're going to have to mock out a bunch of crap in the beginning. You start working blind. As soon as possible, as soon as they're available, you should start using concrete implementations from the other layers. This will identify problems and misunderstandings early. Sure, it will be a little bumpy, but it's a hell of a lot less bumpy than developing independently with a shaky spec and a handshake, and then folding things together late.

My point is, big repo/little repos isn't the issue. What matters is how you structure your teams. Ideally, your teams have small independent identities within a larger cohesive identity. Kinda like organs in an organism or maybe a slime mold. Regardless of how you structure the code, give everyone a chance to bump into each other. Make communication easy. Make mistakes together and fix them early and often.

Answer 2

In my eyes splitting the repository is highly dependent on your goals and the tools you're using.

For example, if you're writing a Ruby on Rails web app without any public (or private) API that your frontend is going to consume (by AJAX for example), then I actually don't see how you could split the repository without causing a massive headache for your team. The Rails framework really works best with a monolithic-type architecture in that case.

However, if you plan on writing an API in Rails or Node.js, but want your frontend written in Ember.js or something else, then it would make sense to split the repository. The same applies if your web app data will be shared in the future by other clients (like via an Android/iOS app). If you plan on writing an API to be consumed by multiple clients, split your repo. Some would argue that even splitting the API into a different application entirely is a bad idea, one that I wholeheartedly disagree with (and it seems so for good reason!

Splitting the repository if you already planned on breaking apart the web app as I described is the only logical option. However, keep in mind that because it will be harder for people to browse each other's code, you need to ensure that you have excellent communication, but even more importantly documentation. Without documenting the API, for example, your other two teams are going to be pissed off very quickly because the API team didn't document the architecture, and your API team will get pissed off because everybody keeps asking them questions. This is even more true for remote teams.

So, it all depends on how you wanted to structure the app in the first place. If you're building a monolithic web app (and you know or sure that it will just remain a web app), then have one repository. If you planned on creating things like microservices or a REST API consumed by multiple clients (or you are planning this for the future), split the repo.