Quote:
Originally Posted by gaming_mouse
no i didn't mean that by "unsee". it makes no difference you have access to the source code. what i'm talking about is either depending on what's supposed to be some internal implementation detail, or else, eg, adding an API call that you want because it's easy, when say the API has already been really well thought out and you don't understand the proper way to use it. whereas if the API is just the API, you have no choice in the matter. and that's a good thing most of the time. certainly if the API has been done well.
it boils down to a fundamental belief that if you just let people do whatever they want, you end with sloppy and entangled. whereas if you have good engineers who own projects, you might end up with something well designed.
Sure I think it's great to have well-thought-out APIs and not so great to have code that depends on undocumented implementation details but I don't see how this has anything to do with the number of repos. The only major sense in which it's related is that in a monorepo setup, when people do **** this up, you can fix it; in a multirepo setup, when people do **** this up, you may be stuck with the consequences forever. The only constant in our industry is that people do **** up and we should design our systems as to minimize the consequences. I'm sort of mixing trunk-based development and the monorepo setup together (the latter enables the former, but does not force it, as I think jj sort of pointed out in different terms) but it is actually the best way to avoid exactly what you're trying to avoid in the long run.
For example, there are all these crazy stories about how the design of Windows evolved around not breaking third-party software:
https://www.joelonsoftware.com/2004/...t-the-api-war/
Quote:
I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
Quote:
Originally Posted by Raymond Chen
I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.
Quote:
A lot of developers and engineers don’t agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It’s why so few applications from the early days of the Macintosh still work.
It's important to see that the multirepo setup in this case, incentivized the original culprit to ship buggy code because it worked at that point in time and they weren't going to be held accountable in the long run. And it incentivized the API developer to ship the terrible workaround because because they had no way to correct the original broken code and they were going to be accountable for the original buggy code written by someone else if they didn't provide the workaround. The incentives are similar in a big company - I don't get to break client code written 3 years ago by someone who's not even there any more and pretend that well, it's not my fault, since it's not something I own. The monorepo (again along with trunk-based development and appropriate tooling) can save the day - you can just fix the client code, which lets you have the cake and eat it, nothing broken and no terrible workaround. If you're paranoid, the monorepo even allows you to enforce this exact thing in ways that's not possible in a decentralized multirepo system - you can search for client code that's doing things that it's not supposed to be doing to warn them ahead of time. If you have the blessings, you can even detect this programmatically and reject commits that are doing this.