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.
I find this stuff to be utterly overkill unless you are building the next Bloomberg terminal (say) and have completely separate teams. Or you have more than say 100 frontend coders working on the same codebase.
If you think you need micro services you are unlikely to need a micro frontend for another order of magnitude of scale. The people talking about both of these things never seem to point out the downsides and huge delivery overheads to these approaches. Much better to make sure you are doing everything perfectly on a single codebase before you take high risk, difficult to manage decisions because you read how cool it was on Martin Fowler’s blog.
So, had gone through samples and my conclusion as a seasoned web dev with projects as big as having thousands of files with hundreds business scenarios, imba is not the setup for this scale.
When people come and go, requirements change, new tools come along, trading flexibility to some initial development boost is not worth it, imo
I understand the complexity issue, and how large corps deal with that stuff... There are other ways you can chunk that stuff up though. Maybe you don't have a choice.
I don't think you can fault Visual Studio for not handling that many projects well.
I have always felt that if you need more than 3 developers and 12 months then the software is too big and the scope needs to be cut down. Better a small program that does one thing well than a monolith that does everything badly - why do we never learn from the UNIX philosophy.
I have a bit of a preference for this approach as well, but having worked on numerous large projects I have to agree with Josh's arguments against it. Maybe on a small personal project it can succeed but on large ongoing projects I favor organizing by function rather than feature.
That's what I do for larger clients or projects, it's just a bummer, that smaller projects need that level of integration to follow best practices these days.
Yeah, it's mostly that--generally also some design stuff to hide it. It's just so tedious, or you can buy into a big framework with all the downsides that implies (big bundle size or a lot of tooling for code splitting).
That's often because most clients will already have some sort of environment set up, running some OS and with certain features installed and most importantly: they don't want to have 5 different projects working on 5 different frameworks because that'd be a nightmare to maintain. Once a company gets into a tech stack, they'll want to stay within it as much as possible and that makes plenty of sense.
It sounds like you're basically saying its difficult and slow to work on large projects, and the solution is to not work on large projects. And that new languages implicitly mean smaller and thus easier projects because they haven't had time to grow.
The weird thing I always get with the always greenfield developers is how you know you aren't just creating even larger messes tomorrow vs the messes you're avoiding today. I guess it isn't your problem though if you're always working greenfield - it's someone else's.
The entirety of StackOverflow runs on something like 4 machines. Abstraction layers are expensive, and having to learn scaling methodologies unnecessarily when a better choice of upfront technology would render it unnecessary is very un-agile.
Why would system load scale with the number of engineers? Yeah. 30 "teams" worth of work can totally fit on one system. The sum total of all software engineering ever done before, I dunno, 1979 can fit on one box.
Really, that's my point. People are far too enthused with the "feeling" of working on a "big" project and not being sufficiently reasonable or conservative about the technologies they try to use.
Cluster deployment for an application this size just isn't needed or appropriate. It's cargo cult engineering, because all the cool kids are using k8s and we want to read about cool kids.
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.
All nice and true (thus upvoted), but it's not really the point he's making. The point he's making is that most modern applications require more than 1-3 developers, and therefore you need to consider the development cost and infrastructure as part of the whole consideration. So he advocates to work on decreasing these costs instead of finding another high-level distributed architecture that is running on centralized infrastructure (the internet) and that is either forgotten in a few months or built by a centralized development organization.
It's fine if you don't care about things like: redundancy/HA, zero-downtime, liveness probes, auto-scaling. So fine for smaller projects. But if you have small project it begs a question why do you have 5 services.
I agree but like everything with optimization and refactoring, the cost to move up towards a 100 offers less ROI in the end. I think if you're at 90 that's solid, no desire to be in the 100 club nor would I tell a client you need to be there.
Sure, they don't have to be efficient so they can afford to spend more on tool development. Not everything works but the better approaches get more adoption.
Also, I think you're underestimating the effects of having a lot of code. This pushes limits that smaller companies don't have to worry about.
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.
reply