3 ms·

I agree with all of them except monorepos. A monorepo might be nice in the beginning for the first 6 months but in the long run, it encourages (facilitates/enab

I agree with all of them except monorepos. A monorepo might be nice in the beginning for the first 6 months but in the long run, it encourages (facilitates/enables) developers to build tightly coupled components so the code base ends up looking like spaghetti and none of the components end up being generic enough to be reusable and that's where the medium and long term costs start adding up. Business domain logic creeps into all the components. I've seen it happen multiple times at different companies. Monorepos don't make sense at face value if you want your code to be modular. How can bringing together multiple modules into a single monolith possibly help to improve modularity. Plato said it best: "You see, it’s not, I think, the function of heat to cool things down, but the opposite." "Nor of dryness to make things wet, but the opposite."

ricardobeat 4y ago
Reusability is a mirage. If you have a monorepo, you don't need to care about reusability outside of that context. Unless you're creating components to be shared with the world, the tight coupling is a benefit, not a disadvantage. Not to say 'spaguetti' code is not an issue, but these are a little bit orthogonal to each other. It's very easy, for example, to grow complexity two/three-fold by trying to make a component more generic and reusable before the actual need arises. And when it does, the original interface you predicted is rarely a good fit.
- bckr 4y ago
  Software engineering is programming over time. At some point the business needs will change. At that point, someone will wish that the Apache server didn't talk directly to the database about last year's invoice minutiae.
  - jongjong 4y ago
    This is spot on. Also, it's one thing to claim that "code maintainability doesn't matter" or that "wasting time constantly refactoring code doesn't matter," it's another to claim "Monorepos are good for software maintainability and help developers make efficient use of their time." I actually do think that code maintainability probably doesn't matter much in the context of many big corporations since they often have market monopolies and can afford to hire huge numbers of developers; they can afford to waste a lot of developer time... That's fair enough, but I don't see why they should be lecturing the rest of us about what good software development practices are. That would be like a rich person lecturing a group of starving people about money not being important. This lesson is completely irrelevant to that audience. Anyone who listens to them will starve to death.

ricardobeat 4y ago

Reusability is a mirage. If you have a monorepo, you don't need to care about reusability outside of that context. Unless you're creating components to be shared with the world, the tight coupling is a benefit, not a disadvantage. Not to say 'spaguetti' code is not an issue, but these are a little bit orthogonal to each other. It's very easy, for example, to grow complexity two/three-fold by trying to make a component more generic and reusable before the actual need arises. And when it does, the original interface you predicted is rarely a good fit.

bckr 4y ago
Software engineering is programming over time. At some point the business needs will change. At that point, someone will wish that the Apache server didn't talk directly to the database about last year's invoice minutiae.
- jongjong 4y ago
  This is spot on. Also, it's one thing to claim that "code maintainability doesn't matter" or that "wasting time constantly refactoring code doesn't matter," it's another to claim "Monorepos are good for software maintainability and help developers make efficient use of their time." I actually do think that code maintainability probably doesn't matter much in the context of many big corporations since they often have market monopolies and can afford to hire huge numbers of developers; they can afford to waste a lot of developer time... That's fair enough, but I don't see why they should be lecturing the rest of us about what good software development practices are. That would be like a rich person lecturing a group of starving people about money not being important. This lesson is completely irrelevant to that audience. Anyone who listens to them will starve to death.