I don't think they did an exceptional job keeping teams separated. In fact, I think monorepos only end up artificially tying teams down with an arbitrary and completely unnecessary constraint.
You just referenced two languages that don’t have proper sum types. lol.
You're complained about "Proper HTTP implementations in proper languages".
I provided two concrete examples of two of the most popular and production-grade programming language ever developed.
I can provide more.
You then tried to weasel out by moving your goal post from "Proper HTTP implementations in proper languages" to "languages that don't have proper sum types".
I won't waste more of my time with you. Whatever you're posting lacks relevance and does not justify any attention from anyone.
I would only recommend a monorepo if you’re a company with at least 5,000+ engineers and can dedicate significant time to internal infra.
It's funny because at least one FANG does not use monorepos and has no problem with them, in spite of being at the same scale or even perhaps larger than Facebook.
I wonder why anyone would feel compelled to suggest adopting a monorepo in a setting that makes them far harder to use and maintain.
(...) you can see what’s going on with the rest of the company, too.
That's a huge security problem.
Edit for those who are down voting this post, please explain why you believe that granting anyone in the organization full access to all the projects used across all organizations does not represent a security problem.
I'm inclined to interpret monorepos as an anti-pattern intended to mask away fundamental problems in the way an organization structures it's releases and dependency management.
It all boils down to being an artificial versioning constraint at the expense of autonomy and developer experience.
Huge multinationals don't have a problem in organizing all their projects as independent (and sometimes multiple) source code repositories per project. What's wrong with these small one-bus software shops that fail to do that when they operate at a scale that's orders of magnitude smaller?
Proper HTTP implementations in proper languages utilize header-name enums for strict checking/matching (...)
I don't know what you are talking about.
Java provides java.lang.Object.HttpHeaders, which is a constants class that provides static final String fields for the popular request and response headers.
.NET does the exact same thing with it's class Microsoft.Net.Http.Headers.HeaderNames.
Bloating HTTP and its implementations for REST-specific use-cases
I have no idea what are you talking about. Setting a request/response header is not bloating HTTP. That's like claiming that setting a field in a response body is bloating JSON.
There are no hard set rules, and it depends on what uses you have for the build number.
Making it a monotonically increasing number helps with versioning because it's trivial to figure out which version is newer. Nevertheless, you can also rely on semantic versioning for that. It's not like all projects are like Windows 10 and half a dozen major versions are pinned at 10.0.
You sound like you're focusing on the wrong problem. You first need to figure it what is your versioning strategy,and from there you need to figure out if a build number plays any role on it.
Ah, the Microsoft tradition of always having the wrong priorities.
I wouldn't be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.
I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?
Also interesting, successful software projects don't just finish and die. They keep on going and adapt changes and implement new features. If we have a successful project that goes on for a decade but we have a clusterfuck of a project which blows up each year for the same time period, by this metric you'll have only a 10% success rate.
It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.
Requirements are not the same thing as specifications either, but both are documentation!
that managers want to stay in control of everything, and they decide whether they do it or not.
That's fine, it's a call from the manager.
That doesn't make it Agile's fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.
So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.
I think you're confusing documentation with specification.
Requirements are specified. They are the goals and the conditions in which they are met. Documentation just means paper trails on how things were designed and are expected to work.
Requirements drive the project. Documentation always lag behind the project.
Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can't accommodate any changes because the process does not have room for those.
This is why this whole "things need to be planned" crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.
Don't blame Agile for your inability to plan. No one forces you not to plan ahead.
The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.
I think you got it entirely backwards.
The whole point of Agile is being able to avoid the "big design up front" approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you're picking up along the way.
The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.
Note that this is failure to deliver on time, not failure to deliver full stop.
It's also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It's easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.
On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development.
I don't think this is an Agile thing, at all. I mean, look at what Agile's main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.
I don't think they did an exceptional job keeping teams separated. In fact, I think monorepos only end up artificially tying teams down with an arbitrary and completely unnecessary constraint.
Also, not all work is services.