"Which is better really just depends on the project."
Yeah, this is always a good perspective. We should never assume that one size fits all, and considering what your project needs is a step we should always go through.
"Any time things are decoupled, you probably want to recouped them to make them useful as a whole."
I don't personally agree with that. By decoupling, we get clear delineation of responsibilities. And these responsibilities typically have very different skills and profiles. In my early career, 20 years ago, I was doing everything in projects, from maintaining the server, to designing the database, all the way through to doing what I was actually good at, which was the front-end development. I could make it all work, but for a professional project, with any significant load or responsibility, my skills in securing infrastructure and guaranteeing databases was firmly in the "I know enough to be dangerous" camp :)
"In the waiter analogy I'm sure we've all had time where there was a miscommunication between a waiter and chef and we didn't get our food."
If you came to my house for dinner, I'd do it all. And that would be fine. But I'd not win any Michelin stars or charge you for your meal. No professional restaurant is set up this way, because of the very different skills and optimisation required. I'm sticking with the analogy!
"recouped" was a typo that should have been "re-coupled". So I would imagine that changes how that sentence was interpreted.
But on that note, I saw a twitter post about an estimation that they spend $200K / year on developer time during the build process. My company spends $0 / year on that. Now I know there can be a separation of concerns even without a build process, but it's just an example of a tangible overhead that comes with separating things. But I'm not saying that's automatically a bad investment. It's just something every company needs to take into account.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"Which is better really just depends on the project."
Yeah, this is always a good perspective. We should never assume that one size fits all, and considering what your project needs is a step we should always go through.
"Any time things are decoupled, you probably want to recouped them to make them useful as a whole."
I don't personally agree with that. By decoupling, we get clear delineation of responsibilities. And these responsibilities typically have very different skills and profiles. In my early career, 20 years ago, I was doing everything in projects, from maintaining the server, to designing the database, all the way through to doing what I was actually good at, which was the front-end development. I could make it all work, but for a professional project, with any significant load or responsibility, my skills in securing infrastructure and guaranteeing databases was firmly in the "I know enough to be dangerous" camp :)
"In the waiter analogy I'm sure we've all had time where there was a miscommunication between a waiter and chef and we didn't get our food."
If you came to my house for dinner, I'd do it all. And that would be fine. But I'd not win any Michelin stars or charge you for your meal. No professional restaurant is set up this way, because of the very different skills and optimisation required. I'm sticking with the analogy!
Ok, I'm hungry now.
"recouped" was a typo that should have been "re-coupled". So I would imagine that changes how that sentence was interpreted.
But on that note, I saw a twitter post about an estimation that they spend $200K / year on developer time during the build process. My company spends $0 / year on that. Now I know there can be a separation of concerns even without a build process, but it's just an example of a tangible overhead that comes with separating things. But I'm not saying that's automatically a bad investment. It's just something every company needs to take into account.