Comment on [deleted]
litchralee@sh.itjust.works 2 days ago
without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others
From the perspective of a user, why would they care about development speed? A user, by sheer definition of wanting to use the software, can only use software that is already developed. If it’s not actually developed yet… they can’t use it. So either they see the software at the end of the development cycle, or they never see it at all. Development speed simply isn’t relevant to a user at that point. (exception: video games, but I’m not aware of any desktop game developed using a web framework)
As for platform consistency, again, why would the user care? Unless each user is actually running the same software on multiple platforms (ie a Windows user at work, Arch at home, and BSD at their side-gig), this is a hard sell to get users to care. A single-platform user might never see what the same software looks like on any other platform. Even mobile apps necessarily differ in ways that matter, so consistency is already gone there.
What I’m getting at is that the concerns of developers will not always be equally concerning to users. For users to care would be to concern themselves with things outside of their control; why would they do that?
nikolasdimi@lemmy.world 2 days ago
hm…great points, thanks for taking the time to answer.
From the perspective of a user, why would they care about development speed?
Yes, the tool is already developed but it will continue evolving right? I mean, we almost make 2-3 releases every month since we shipped the first version and then open sourced. So the speed still counts. Plus, the users who create the tickets and expect them to be tackled are actually developers themselves. So yeah, the ability to deliver (at a good pace) to these folks matters a lot.
However - YES, if at some point the tool is at a state that the speed becomes less meaningful or useful, then indeed a change might be needed?
As for platform consistency, again, why would the user care?
Yes, since our users are Dev (and QA) folks, we thought that yeah, maybe someone could have different systems for work vs home vs side project (as you said). But another aspect that we thought is teams and collaboration. We didn’t want to have a scenario in which a team can not use it before some of the devs are using macs, others linux vs the QA folks using windows etc.
What I’m getting at is that the concerns of developers will not always be equally concerning to users.
Thats the heart of the discussion:) I guess because our users are also developers. :)