4 ms·

Unfortunately users just don't care in most cases. The app stores have taught a generation of users that software should be free so the pressure is on developer

Unfortunately users just don't care in most cases. The app stores have taught a generation of users that software should be free so the pressure is on developers to build things in the cheapest way possible. In most cases that takes real native apps off the table. I particularly blame Apple here for being so successful at commoditizing software in order to sell their hardware. This might come back to bite them now that their hardware sales are slowing though. In markets where users are still willing to pay a premium you still see high quality native apps. Ableton Live is $750, but plenty of users are happy to pay that because you can't build Live with javascript and html.

dTal 8y ago
It's not clear to me that this is actually a bad thing. Computer time is less valuable than human time, and that goes for both developers and users. For most one-off computing tasks, far better to fumble with something shoddy but free that someone dashed off in a few hours, than invest a day's wages into a product with man-years worth of polishing. There's free food everywhere and we're complaining it's not gourmet.
mr__y 8y ago
>Unfortunately users just don't care in most cases. Users almost universaly don't care. This also applies to businesses, C-levels and managers. However, while they don't care it affects them indirectly as they end up using bloated sub-optimal software possibly with bugs and sometimes significantly slower than in could be. It then affects their productivity as well. My point is that one could at least try educating the non-IT decision makers why it's important. My team has successfuly convinced the CEO that 2 month long refactoring project is really important and that while it won't directly affect the functionality it will increase productivity of the our team in future by making the team more productive and allowing for faster implementation of new features in the future. From my experience the "technical debt" metaphor is great for explaining such things to business oriented people. That metaphor is usefull because it is compatible with other debt related metaphors, like interest rate or refinancing. We could explain extra time needed to implement stuff in non-refactored bloated codebase as an interest-rate. Also, the use of car-related analogies is quite effective. My point is that while users don't care about the technological intricacies, the effects can be explained by the use of metaphors and concepts that they know well.

dTal 8y ago

It's not clear to me that this is actually a bad thing. Computer time is less valuable than human time, and that goes for both developers and users. For most one-off computing tasks, far better to fumble with something shoddy but free that someone dashed off in a few hours, than invest a day's wages into a product with man-years worth of polishing. There's free food everywhere and we're complaining it's not gourmet.

mr__y 8y ago

>Unfortunately users just don't care in most cases. Users almost universaly don't care. This also applies to businesses, C-levels and managers. However, while they don't care it affects them indirectly as they end up using bloated sub-optimal software possibly with bugs and sometimes significantly slower than in could be. It then affects their productivity as well. My point is that one could at least try educating the non-IT decision makers why it's important. My team has successfuly convinced the CEO that 2 month long refactoring project is really important and that while it won't directly affect the functionality it will increase productivity of the our team in future by making the team more productive and allowing for faster implementation of new features in the future. From my experience the "technical debt" metaphor is great for explaining such things to business oriented people. That metaphor is usefull because it is compatible with other debt related metaphors, like interest rate or refinancing. We could explain extra time needed to implement stuff in non-refactored bloated codebase as an interest-rate. Also, the use of car-related analogies is quite effective. My point is that while users don't care about the technological intricacies, the effects can be explained by the use of metaphors and concepts that they know well.