Hi,<p>I’m a product manager learning the craft. Coming from UI/UX design background.<p>I’m currently building a couple of products with developers who’ve chosen the MERN stack. My question is about “replaceability” — how tied am I to a front end developer on the MERN stack and how tied am I to a back end developer on this stack?<p>Which one am I closer tied to?<p>When I say replacing someone, I’m wary of the cost of switching the developer who made the app/wrote the code with a new one:
1. the time cost of finding them
2. time cost of them going through the previous developer’s code to understand what’s going on there
3. Money cost etc<p>As far as I understood (correct me if I’m wrong please), the point of using the React framework is that it’s all “modular” and that the cost of switching developers is lower. Would appreciate someone shedding some light on me!
Yikes. If the thing you're worried about the most is how replaceable your staff is, there's something smelly going on ...<p>That said, any web developer worth their salt should just be able to pick up any tech like Mongo or React with ease. There's enough resources out there that wouldn't mean this is an issue.
It's a common stack, so no more or less replaceable than any other stack such as any other permutation of (Mongo/MySQL/PostGresql/SQL Server) + (Express/Rails/Django/ASP.NET) + (React/Angular/Vanilla) + (Node/Ruby/Python) etc.<p>React is as modular as the developers choose it to be. You can write convoluted code in React too. React does force you into a certain way and makes it easier to standardise, but these days with hooks and Redux and much more there can be a lot of variation in architectural styles.<p>Picking what tech to use is hard. Sometimes it doesn't matter at all, just pick what you are used to. Case in point most peoples SaaS side projects.<p>Sometimes it makes all the difference. If using clojure + scala + akka + kafka + prolog means you can crush the problem, then choose those, don't pick worse languages for solving a given problem so you can handle people leaving.<p>I suspect developer replacability should never be that much of a concern in the choice of tech, where you are even considering something esoteric for genuine reasons.
You can ask your team about the flexibility of their architecture. How easy is the current setup such that new team members can be added, how piecemeal are the components and apis such that tasks can be delegated.<p>It’s fair to be concerned that one or very few own your product implementation (and I speak as a developer).<p>MERN stack is okay, but it can easily have ten other pieces that will make it a highly specialized stack.<p>Things should be designed so you can rip out any of those letters. If you end up with a convoluted UI codebase, it will cost money and time to rip the R out.<p>If you don’t get the right people to setup your database right, you won’t be able to pull the M out.<p>The E and N are probably the hardest to mess up amongst the letters.<p>Don’t add anymore invisible letters to the stack if you can avoid it (there’s a plethora of extra stuff a typical full stack dev now days is prepared to pull in if you search around).
I would stay away from mongo as a database depending on what you are doing (in almost all cases, you don't need mongo. There are better options). Tech debt from mongo can pile up soon. Can you explain more about the product?<p>React is alright. Make sure to use hooks instead of classes and encourage semantic separation. Separate by the use case of the component. Too often people either end up with too big files doing everything or too many small files that should just be a one file.<p>Use typescript and jsdocs. It will help you make less bugs and help unfamiliar devs quickly start working.<p>Use something like nestjs to give structure.<p>Other than that, you are good to go.
I think you are too highly tying a developer to a specific technology.<p>Asking which one you are closer tied to reveals some inexperience in your product management role. Yes there is always a cost to finding new developers and having them ramp up on the codebase. And some of this can be mitigated by hiring developers who are familiar with the stack you've chosen. However the ROI you will get hiring a good developer who needs to learn your stack is much higher vs a mediocre developer who is familiar with your stack.
> As far as I understood (correct me if I’m wrong please), the point of using the React framework is that it’s all “modular” and that the cost of switching developers is lower.<p>I think your mental model of React may be incorrect. The point of using React is to make front end development easier and more sane, and the modularity allows for more easy re-use and composability. Switching developers still requires ramp-up, although a developer familiar with React would have a head start.
I wouldn’t worry about it. If you know JavaScript and/or *script (any of the more strongly-typed derivatives), going from React to Angular and back is pretty easy. If you’re willing to be more flexible with people coming from other languages, the db/web/ui/app stack has been a thing for a long time and the basic premise of how it works is the same