4 ms·
All engineering requires trade offs, in this case you’re trading productivity in one area vs flexibility.
by haney 8y ago
All engineering requires trade offs, in this case you’re trading productivity in one area vs flexibility.
- filleduchaos 8y agoAll engineering may require tradeoffs, but when you're so prioritizing developer experience over the actual business that you're dropping perfectly viable features just so you can cling to the illusion of increased productivity, perhaps it's time to take a step back and reevaluate things. What use is "productivity" without a performing product?
- Jare 8y agoMVPs are mostly about that. Unless a fancy feature not supported by RN is a necessary part of your core product, productivity takes priority.
- filleduchaos 8y agoAnd is the app going to remain an MVP forever?
- Jare 8y agoNo, but the ability to produce an MVP within the limitations (time, budget, opportunity, etc) may be what allows having an app at all.
- spamizbad 8y agoDepends on what feature we're talking about. Is it a high-value feature to the end users? Then absolutely, you're correct. Anyway, in my experience, most good PM and designers want an understanding as towards the amount of effort their features and designs mean for engineers. So if you aren't providing them that feedback, and letting them to factor that into their process, you're doing them a disservice.
- on_and_off 8y agoso productivity as long as you don't implement some features ? I mean, I can double my native productivity that way too !
- haney 8y agoSure, I’m not advocating for developer experience above all else, just pointing out that the fast/cheap/good “pick any two” balancing problem can be solved in multiple ways. I totally agree that we build products for our users not ourselves.
- on_and_off 8y agooh yeah, I can get behind that. If you need an app on both Android and iOS quickly, have low quality concerns and only one web dev .. RN is a no brainer. It kinda occupies a completely different valley of the fast/cheap/good graph