Yep, I feel the same way, but then again I usually work with small startups. I had an experience with a bigger team, recently (about 20 devs) and went all the way "what you do is too complicated". I was quickly humbled when I realized that my "simple" designs were quickly growing out of control and breaking a lot after a few months so many devs were adding code in it, most of them knowing only a very small part of the app. I guess I could say no product should need 20 devs, but it feels like denial.
So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :)
> So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :)
Hmm, if each component is properly isolated though and you're not all working on the same area I still don't see why a simple modal could take so many code changes. Can you give an example?
I've worked on Java codebases before where there's hundreds of abstract interfaces, factories, design patterns galore etc. where you can't work out where the actual work is done because every file is just delegating to another file which I hate with a passion. JavaScript gets a lot of stick around here but I find it fun and productive to work with to be honest, as long as the same silly level of abstraction is avoided.
Oh, no, absolutely no real life example. Note that something that huge is not something I encountered (gladly, 20 devs was the biggest team I was in). I'm trying to answer the question "in which circumstances people doing this may be right", which is my usual approach when I don't understand a behavior (provided it's not morally questionable behavior, obviously, but it's not the case here).
And I totally get what you mean with over-abstractions, many rails teams have the same problem, nowadays. I'm not advocating that, just trying to understand why it makes sense for them, and which problems they have that I don't.
So, if I had to give an hypothetical example, I would go with a chart modal on an e-commerce, like amazon. You have the list of items with their quantity, in it, quite basic, and a few devs are responsible of that part - those who manage checkout base code.
But you want your modals to look the same all over the domain, so you make an abstraction for it, made by a team who work on abstraction for the whole domain, expecting to be used in a certain way, but trying to avoid preventing devs to implement what they need.
Now, the thing with checkout is that there are a lot of legalities which vary upon countries. You have developers in those countries, so why not make them work on the specific VAT, legal mentions, or whatever that they're already used to, instead of having a team who should get all the different legal frameworks of all countries in the world? Or you can split responsibilities about those to various teams, each handling several countries, but none having to know the law of all countries. To do that, you'll probably add an API in the basic chart component and allow different teams to plug on it.
And then, there's the team handling promotional content. Most of the time, they can do with existing abstractions, but sometimes it requires new specific content, so you decide to have a team on that, since you're a giant and you deal with several promotions a day.
All those people keep editing the same feature, but none know the whole codebase for it, so they have to be pretty sure they won't break someone else part by making a change.
And now, people in all those teams keep coming in and leaving company, and you have to make sure no knowledge is lost when they leave, and that new people can make changes fast. If you split all of this in 30 files with a clear separation of public api and internals, it probably helps.
This is my best - although probably naive - guess of where an over-specified architecture may be useful for a modal.
> Oh, no, absolutely no real life example. Note that something that huge is not something I encountered (gladly, 20 devs was the biggest team I was in). I'm trying to answer the question "in which circumstances people doing this may be right", which is my usual approach when I don't understand a behavior (provided it's not morally questionable behavior, obviously, but it's not the case here).
Well I've been on teams on two where the software architect would insist on abstractions and dependency injection absolutely everywhere so it's probably not team size dependent. :P
I find it funny how some people promote the "you aren't gonna need it" principle but yet abstract absolutely everything in the incredibly slim chance they might want to swap something out in the future. I feel overabstraction is a very, very bad and common thing yet it is rarely mentioned compared to e.g. avoid goto, avoid comments. Overabstraction bloats your code and makes it really hard to understand.
> And now, people in all those teams keep coming in and leaving company, and you have to make sure no knowledge is lost when they leave, and that new people can make changes fast. If you split all of this in 30 files with a clear separation of public api and internals, it probably helps.
I could imagine how if you were dealing with Amazon's scale abstraction would be more common and more useful than in other places.
Yeah, totally, small and medium teams don't need all of those. That was my initial point about implementing our own flux-styled store layer for react, instead of using flux (the actual lib) or redux, which are made for such giants.
We have a big problem with small companies wanting to imitate giants and go with elasticsearch/kubernetes/rabbitmq/whatever from the start when they clearly don't need those (and the same goes for code architecture).
I just won't say that the simple architectures I write are how everybody should write code and that giants' devs are bad developers for solving problems I don't have :)
So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :)