Generally you're probably right, but it does depend on how many users you have.
Not speaking from experience, but I'd presume there are quite a few custom software projects that are designed for one single client running on a cluster of handful of machines.
From experience, the factor is more like 5-10. Depending on the complexity of the existing solution, and depending on the wealth of custom implementations, of course.
I agree that pretending you have multiple clients sets up a more difficult bar to meet. I agree that bar might be overkill for some projects.
The idea that it is overkill for all projects is a leap I can't follow. Optimizing for greenfield development speed is something inexperienced devs often do, and that's what this feels like.
My main project has ~30. But still I prefer to go one at a time, especially with a major version bump, for the sake of understanding exactly what breaks. Perhaps it's just a personal preference.
Tens to low hundreds possibly, but micro services can make things much worse as you scale to thousands of developers. The ultimate limit of any design is how much any one person can understand both from both a complexity standpoint and a rate off change standpoint. It’s the same issue that pushed people from goto > functions > libraries > ... Eventually you need another layer of abstraction.
For very large companies doing mergers etc things are always going to be in flux in ways that the startup world tends to ignore.
DID is an extremely important concept that is alien to a lot of developers: Deploy for 1.5X, Implement for 3X, Design for 10X (your numbers may vary slightly)
For personal projects it might be overkill depending on the scope. But if 2+ people are working on a constantly evolving system, shipping new features, and want consistency in the design system? It’s a solid foundation.
In most cases, I'd think those small teams support like a max of 5 ABIs, out of the 176.
Of course it's "possible". Of course, complaining about it won't get it done. But I can easily envision an alternate universe with the same OS & CPU architecture variety, that has the effort required for doing this be ten times smaller, and I don't see it being utterly pointless to ponder the viability of that if only just for fun (which the swearing in the article hints to me it is).
I, as an author of a small language implementation, would really prefer to not need to implement more than one
C FFI ABI, much less 176. I'd meet somewhere in the middle, but 176? nah.
Yup, when you have one production server or maybe two for good measure, you don’t need a big layer of abstraction on top.
“We don’t need to do very much so we don’t do very much” is a good place to be, what is hard is deciding what and when for building out abstractions. Almost everywhere does it way too early or way too late.
As mostly an engineer (though I've spent time as a tech/team lead and engineering manager in the past), I think you've missed the point.
Most of the things will not need to be "scaled" at all. Ever.
As an engineer, I mostly struggle to come up with a simple solution while accommodating all the crappy, leaky abstractions in the rest of the code: that's the hard part of the job. And 20 years in, I still wonder why people think it's smarter to introduce seventeen layers of abstractions for things that have one or at most two implementations, but that's what they do.
120 is not that high. If you have fine-granular modules for re-use across multiple product lines, you need lots of projects. Yes, one can create several solutions for each line, but many times one needs to load all the projects especially feature teams that touch a little-bit everywhere.
I think the choice is to give as few as possible. Not only will that help minimize development time, but you can always add based on what users demand.
I believe you have me wrong here, just on being able to make the application (yc, etc) hurdles. I have 30,000 + users in nearly 15,000 different organizations using the system I have developed.
I am also about to release a version that works & acts like ning.com, and versions targeted towards specific verticals (all that run on the same base of code, so there is no code duplication at all).
You don't design the abstraction for 3 different clients as often as you abstract it from code used by 3 different clients.
reply