3 ms·

Maybe it's time to wonder if it's not how you arrange the files?

by lugged 5y ago

NavinF 5y ago
Monorepos have nothing to do with arranging files. It's all about making atomic commits to multiple projects simultaneously.
- dboreham 5y ago
  I'd argue that it's not. The atomic commit thing is cited because it's about the only argument in favor of monorepo that has technical merit. So a smart debater will latch onto that argument knowing it is hard to defeat. imho it is all about inertia and laziness: an organization begins with little code and one repo. They grow. They write more code. They acquire more code. Nobody is interested in stepping forward to do the hard work of managing all this code. So the repo gets bigger and bigger with more and more discrete projects inside it, until the situation becomes largely unworkable (e.g. clone the tree takes 20 min, CI builds of different projects don't work because tools used can't deal with multiple projects in the same repo). Then people justify their mess with arguments about sharing code and atomic commits. Also I'd argue it is to some extent about lack of knowledge -- people may just not be familiar modularity mechanisms that will solve their problems, because they've always depended on code being in the same repo.
  - lhorie 5y ago
    The atomic commit thing is just a means to some ends. Some ends are indeed easier to achieve with monorepos. Security audits/patching is one example I've dealt with in the past (dealing w/ supply chain vulns in a multi-repo world is a goddamn nightmare). Cross-package integration testing is another example. The thing about projects getting bigger is orthogonal to whether people pick monorepos or not. Many project feature sets are simply complex in a way that you can't refactor your way out of. When I hear this argument that projects could somehow be made smaller, typically it's from someone who's never had to deal with the regressions of such a decision or someone who's never had to be accountable for their estimates. I've seen firsthand projects that got rewritten with the benefit of hindsight, proper staffing, management blessing and all the jazz, and still struggle to meet feature parity of their older counterparts. It's clearly not a question of being interested in putting in the work, or even having the budget for it. From what I've seen, messiness is largely a function of experience. A lot of people simply don't have experience in writing libraries and/or architecting systems. I find that once they acquire the skills, quality of encapsulation improves a lot. FWIW, I think monorepos help with that transition because it provides that fast feedback loop of single repos while a developer is learning the ropes of how to librarize, instead of getting bogged down waiting on slow code review/CI/publish feedback loops.
  - scotty79 5y ago
    People with monorepo just want to have versioned filesysytem. They don't care about splitting and separating stuff. Should managing all this code be hard work? I don't blame people who want to skip that.

Maybe it's time to wonder if it's not how you arrange the files?

by lugged 5y ago

Maybe it's time to wonder if it's not how you arrange the files?

Monorepos have nothing to do with arranging files. It's all about making atomic commits to multiple projects simultaneously.

dboreham 5y ago
I'd argue that it's not. The atomic commit thing is cited because it's about the only argument in favor of monorepo that has technical merit. So a smart debater will latch onto that argument knowing it is hard to defeat. imho it is all about inertia and laziness: an organization begins with little code and one repo. They grow. They write more code. They acquire more code. Nobody is interested in stepping forward to do the hard work of managing all this code. So the repo gets bigger and bigger with more and more discrete projects inside it, until the situation becomes largely unworkable (e.g. clone the tree takes 20 min, CI builds of different projects don't work because tools used can't deal with multiple projects in the same repo). Then people justify their mess with arguments about sharing code and atomic commits. Also I'd argue it is to some extent about lack of knowledge -- people may just not be familiar modularity mechanisms that will solve their problems, because they've always depended on code being in the same repo.
- lhorie 5y ago
  The atomic commit thing is just a means to some ends. Some ends are indeed easier to achieve with monorepos. Security audits/patching is one example I've dealt with in the past (dealing w/ supply chain vulns in a multi-repo world is a goddamn nightmare). Cross-package integration testing is another example. The thing about projects getting bigger is orthogonal to whether people pick monorepos or not. Many project feature sets are simply complex in a way that you can't refactor your way out of. When I hear this argument that projects could somehow be made smaller, typically it's from someone who's never had to deal with the regressions of such a decision or someone who's never had to be accountable for their estimates. I've seen firsthand projects that got rewritten with the benefit of hindsight, proper staffing, management blessing and all the jazz, and still struggle to meet feature parity of their older counterparts. It's clearly not a question of being interested in putting in the work, or even having the budget for it. From what I've seen, messiness is largely a function of experience. A lot of people simply don't have experience in writing libraries and/or architecting systems. I find that once they acquire the skills, quality of encapsulation improves a lot. FWIW, I think monorepos help with that transition because it provides that fast feedback loop of single repos while a developer is learning the ropes of how to librarize, instead of getting bogged down waiting on slow code review/CI/publish feedback loops.
- scotty79 5y ago
  People with monorepo just want to have versioned filesysytem. They don't care about splitting and separating stuff. Should managing all this code be hard work? I don't blame people who want to skip that.