Even if the AI piece isn't really true - smaller flatter teams will move faster anyway. I always wonder having worked in a lot of startups with 10-50ppl, what on earth a business does with 10000.
> I always wonder having worked in a lot of startups with 10-50ppl, what on earth a business does with 10000.
If a small business needs to send a replacement widget to a customer in a foreign country, they label it "$0 value" (as it's a free replacement part) and mail it with a swipe of a corporate credit card.
If a large business needs to do the same thing, the sender asks the mail room, giving them a budget code and delivery address; the mail room contacts the widget designer for a HTS code, size and weight; then contacts their shipping broker for a quote; then contacts the finance department to raise a purchase order; the finance department contacts the budget code owner for spend approval; then raises a purchase order; then forwards it to the sender who forwards it to the post room who forwards it to the shipping broker who arrange a collection. Later the shipping broker will send the post room an invoice against the purchase order, which they'll send on to finance, who'll query the sender who'll approve paying the invoice.
> Even if the AI piece isn't really true - smaller flatter teams will move faster anyway.
Quite possibly - but you have to remember to remove the bureaucracy, not just remove the people who operate the bureaucracy. If you try to do the large business process with the small business team, it'll be even slower.
Seconded. My experience has been that -- even while still complying with lots of overhead (e.g. government regulations and compliance) -- smaller teams of 1-3 devs move waaaaay faster than teams of 4-10. Could definitely speak to the overall codebase quality or some other factor, but yeah.
I found this an interesting question and did some research out of curiosity
[Full credits to wikipedia]: https://en.wikipedia.org/wiki/Star_Division (The company behind what's gonna be essentially StarOffice/Later OpenOffice/Libreoffice given Libreoffice is a fork of OpenOffice)
Star Division was a German software company best known for developing StarOffice, a proprietary office suite. The company was founded in 1985 by 16-year-old Marco Börries in Lüneburg, and initially operated as a small startup. Its first product was StarWriter, a word processor that later evolved into the StarOffice suite.
Their number of employees by the late 1997/1990's from the wiki article suggests
170. They/StarOffice achieved over 25 million sales worldwide and held an estimated 25% share of the office suite market in Germany by the late 1990s
There seem to be 5 main members (I am not counting the Gitlab Admin and administrator)
Interestingly, If I remember correctly, I saw Alexandar Franke in here, I have actually talked to alexandar franke a long time ago on matrix back when I used to use fractal. It was definitely a fun surprise to see him in this project as well.
Aside from that, I think the problem with MS word to me feels like it tried to copy the features of previous word processors including quirks and now anything which wants to be MS word competitor is sometimes forced to copy these quirks as well which to me feels like the stressful cause for the reason why we don't see too many new approaches within this space (in my limited opinion)
Yeah what I really meant is imagine if you reduced the actual MS Word team to just 3 people. They would not move fast because by this point Word is an enormous mature project and they wouldn't even be able to touch 1% of it.
Brooks explains this in The Mythical Man Month when he discusses how adding people to a delayed project increases the delay. Communication complexity grows exponentially as team size increases. It quickly reaches the point where it has to be controlled by procedures, forms, approvals, etc.
They're still a megacorp, roughly, with like 6k people remaining. That's a huge company. Huge companies need hierarchy to function, the "flat" thing is a really dumb idea. There's no way to make it analogous to that <50ppl team that executes well and moves fast. To do that you actually need to have a small company.
First you take a 50 person org. Then (for scale) you hire highly motivated performers who, because they came up in big orgs, are used to using 50 people for three years to do a project six people can do in three to six months. Then you create incentives that make them compete for standing. And the standing also depends on their personal scope (ie headcount).
If you have a database, you still have work to do - optimizing, understanding indexes, etc. Managed services don't solve these problems for you magically and once you do them, just running the db itself isn't such a big deal and it's probably easier to tune for what you want to do.
Absolutely yes. But you have to do this either way. So it's just purely additive work to run the infrastructure as well.
I think if it were true that the tuning is easier if you run the infrastructure yourself, then this would be a good point. But in my experience, this isn't the case for a couple reasons. First of all, the majority of tuning wins (indexes, etc.) are not on the infrastructure side, so it's not a big win to run it yourself. But then also, the professionals working at a managed DB vendor are better at doing the kind of tuning that is useful on the infra side.
Maybe, but you're paying through the nose continually for something you could learn to do once - or someone on your team could easily learn with a little time and practice. Like, if this is a tradeoff you want to make, it's fine, but at some point learning that 10% more can halve your hosting costs so it's well worth it.
It's not the learning, it's the ongoing commitment of time and energy into something that is not a differentiator for the business (unless it is actually a database hosting business).
I can see how the cost savings could justify that, but I think it makes sense to bias toward avoiding investing in things that are not related to the core competency of the business.
Depends on how data-heavy the work is. We run a bunch of gpu training jobs on other clouds with the data ending up in S3 - the extra transfer costs wrt what we save on getting the gpus from the cheapest cloud available, it makes a lot of sense.
Also, just availability of these things on AWS has been a real pain - I think every startup got a lot of credits there, so flood of people trying to then use them.
The key I think with s3 is using it mostly as a blobstore. We put the important metadata we want into postgres so we can quickly select stuff that needs to be updated based on other things being newer. So, we don't need to touch s3 that often if we don't need the actual data.
When we actually need to manipulate or generate something in Python, we download/upload to S3 and wrap it all in a tempfile.TemporaryDirectory() to cleanup the local disk when we're done. If you don't do this, you end up with a bunch of garbage eventually in /tmp/ you need to deal with.
We also have some longer-lived disk caches and using the data in the db and a os.stat() on the file we can easily know if the cache is up to date without hitting s3. And this cache, we can just delete stuff that's old wrt os.stat() to manage the size of it since we can always get it from s3 again if needed in the future.
I wonder if they regret the name change - like don't rename the whole company after a research project because when it fails people are eventually going to be like 'wtf is a meta?'
Also rebasing is just so fraught with potential errors - every month or two, the devs who were rebasing would screw up some feature branch that they had work on they needed and would look to me to fix it for some reason. Such a time sink for so little benefit.
I eventually banned rebasing, force pushes, and mandated squash merges to main - and we magically stopped having any of these problems.
We squash, but still rebase. For us, this works quite well. As you said, rebasing needs to be done carefully... But the main history does look nice this way.
reply