2 ms·

That is not how an engineer should think. An engineer designs the right tool for the job and does so as efficiently as possible (think money and time-wise). Say

That is not how an engineer should think. An engineer designs the right tool for the job and does so as efficiently as possible (think money and time-wise). Say customer wants an app where its clients login, fill a couple of forms, do a couple of queries. What would a well trained engineer do for such app? Spend 4x to gain a 5-10% better UI experience and maybe a 30-40% battery efficiency? Or, would she sacrifice a bit of both but deliver a single code base that solves the problem? Now, if such engineer faces a game or a camera/gps intensive app, she would probably choose native. In any case, the good engineer never generalizes the solutions. Context is crucial.

dleslie 10y ago
And then every "good engineer" who adopts this means of defining success is in part responsible for the unresponsive UIs and spotty battery lives of devices running anything other than stock software. "Why is my phone running so hot and always in need of charging halfway through the day?" Well, 5% CPU here, a battery-draining busy loop there... But the solutions solved the minimal target; so suck it up, end-user.
khedoros 10y ago
>What would a well trained engineer do for such app? If those were the limits of the requirements, then yes. Your job is to fill the requirements while minimizing dev costs. Sometimes that means some compromises in latency, or other aspects of UI polish. As a dev, that's understandable. As a user, it's annoying, and I'm going to look for any option that lets me do the same thing while avoiding the annoyance. The software has to provide an overwhelming benefit to make it worth my while (e.g. my laggy banking app that lets me remotely deposit a check). Honestly, I don't know much about UX and customer engagement or how much it hurts a company if a customer waits to get to their PC to use a service, but it seems like a concern that's often downplayed when the requirements list is being written.

dleslie 10y ago

And then every "good engineer" who adopts this means of defining success is in part responsible for the unresponsive UIs and spotty battery lives of devices running anything other than stock software. "Why is my phone running so hot and always in need of charging halfway through the day?" Well, 5% CPU here, a battery-draining busy loop there... But the solutions solved the minimal target; so suck it up, end-user.

khedoros 10y ago

>What would a well trained engineer do for such app? If those were the limits of the requirements, then yes. Your job is to fill the requirements while minimizing dev costs. Sometimes that means some compromises in latency, or other aspects of UI polish. As a dev, that's understandable. As a user, it's annoying, and I'm going to look for any option that lets me do the same thing while avoiding the annoyance. The software has to provide an overwhelming benefit to make it worth my while (e.g. my laggy banking app that lets me remotely deposit a check). Honestly, I don't know much about UX and customer engagement or how much it hurts a company if a customer waits to get to their PC to use a service, but it seems like a concern that's often downplayed when the requirements list is being written.