8

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.

Community
  • 1
Silver
  • 183
  • 3
  • By repository, do you mean code repository (ala git or svn)? – Jay Elston Dec 15 '15 at 00:09
  • Scant is correct in that splitting the team is a much bigger issue than the splitting the repo. The team I work in has a few dozen repos but we're still one team. – Ixrec Dec 15 '15 at 08:22

2 Answers2

4

"...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.

Scant Roger
  • 9,038
  • 2
  • 29
  • 47
  • I disagree with most of this answer. Communication is of course important, but; just because you split the code base into multiple repositories, there's: 1. collaboration - collaborators can view the code base (and modify if they really need to), 2. **documentation**. If you're building a REST API separately from the frontend, the API can be very well-documented and no hassle ensues (unless you have really novice front-end developers or crap documentation). How do I know? I write/maintain a REST API that is used by third-party developers, and I get maybe one email per week about how to use it. – Chris Cirefice Dec 15 '15 at 12:26
  • @ChrisCirefice That's another approach entirely. It's a different kind of beast to co-develop a system rather than developing a part of it. In your case front-end developers adapt to your decisions but in op's case the backend decisions are taken parallel to the needs and wants of the front-end – Machinarius Dec 15 '15 at 12:45
  • @Machinarius That's more or less true. My boss mocks up the frontend and makes all of the decisions on how the app should look/function. The frontend developers get to working on the skeleton, I develop the necessary API endpoints in the backend, and the frontend guys then plug in API calls to get the data in parallel. This is done on a week-to-week basis, so I don't see much of a difference in my case, and it still works just fine. Separate developers are working on different aspects in tandem, though that obviously wasn't mentioned in my previous comment. – Chris Cirefice Dec 15 '15 at 12:48
  • Our team has one backender, one guy for writing and maintaining the services, two front enders, two guys working on the mobile version, and the team leader, also our boss, who's in charge of making things work. We hardly touch any code beyond their area. The communication issues are real, as with any team, but splitting the team wont be a problem, as we already work independently. Thanks for your answer, as it gave me some insight to show to the team leader. – Silver Dec 15 '15 at 15:10
1

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.

Community
  • 1
Chris Cirefice
  • 2,984
  • 4
  • 17
  • 37
  • A single repo doesn't have to be a monolith. Physical and logical layers _can_ be stored in separate repos, but they don't have to be. A single repo can contain a backend API as well as other layers. The burden of communication (documentation is part of communication) is no more or less with one big repo or several small repos. That's my point -- the repos don't matter. What matters is how your team/teams think about problems and work together to solve them. – Scant Roger Dec 15 '15 at 13:43
  • We have the app already separated in distinct entities. The backend and the services are on one side. The front end only consumes the services via client. Our front enders only know how the services work. Our team has one backender, one guy for writing the services, two front enders and two guys working on the mobile version, and they hardly touch any code beyond their area. – Silver Dec 15 '15 at 15:01