5 ms·

Is no one on HN willing to wrestle with the actual premise of the article? > A rhetorical substitution of developer value for user value [...] > The “developer

Is no one on HN willing to wrestle with the actual premise of the article? > A rhetorical substitution of developer value for user value [...] > The “developer experience” bait-and-switch works by appealing to the listener’s parochial interests as developers or managers, claiming supremacy in one category in order to remove others from the conversation [...] The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true. > Shifting the conversation away from actual user experiences to team-level advantages enables a culture in which the folks who receive focus and attention are developers, rather than end-users or the business. It naturally follows that teams can then substitute tools for goals. Our community is absolutely infested with this attitude right now. Tell me: When was the last time someone provided battery life impact numbers for React Native? If you use it, was that even part of your evaluation criteria? The OP is absolutely right: there is massive conflation of _developer convenience_ with _user experience_. The modern frontend web dev scene is merely one of the symptoms. The fundamental assumption that "good for developers" must by definition equal "good for users" is a) usually unstated and b) absolutely unquestioned. I agree with the OP that it is also often c) wrong. In some cases necessity has caused some developers to internalize and stockholm-syndrome themselves into believing some cross-platform monstrosity or PWA-in-a-mobile-app is better or just as good as a native mobile app. Not because it is, but because they have no choice given their current budget and staffing constraints. A successful startup requires clear level-headed thinking. Do not mistake expedient or necessary decisions for optimal ones and be willing to re-evaluate your strategy at any time. Above all don't talk yourself into believing user experience doesn't matter.

linuxftw 8y ago
We live in a world of 'ship MVP, gather customers, exit' Of course the developer experience is going to be front and center, when you're trying to start a new product and don't want to invest actual money into it for real developers, you need something quick and dirty to move the project along. I'm firmly in the camp that javascript 'webapps' are crap and make the web less web-like, the web I came to enjoy. I reluctantly admit that the ship has sailed and I enjoy the web less now.
- chillacy 8y ago
  Customers are somewhat complicit too, by choosing buggy products with more features over stable products with less. It turns out having a buggy product is still more desirable than not having the product at all. Also if asked to put a price on stability or performance... I suspect that number is going to be smaller than necessary.
  - linuxftw 8y ago
    I think the take away lesson is: Don't write great software, have a great sales team. At least, that seems to be the sentiment of all the failure stories posted around these parts.
    - TheHegemon 8y ago
      Working in enterprise software I unfortunately agree with that statement. Our product is terrible and yet we can signing all of these giant contracts. It is a bit disheartening to realize as long our stuff "almost works" and we keep pushing out features then we will keep growing.
      - linuxftw 8y ago
        > Our product is terrible and yet we can signing all of these giant contracts. It is a bit disheartening to realize as long our stuff "almost works" and we keep pushing out features then we will keep growing. If you have an enterprise support model for your product, client turnover would be a leading indication of how successful the software really is. High renewals and good margin is a successful software product. Whether or not the companies that buy it are completely wasting their money doesn't seem to matter much as long as they all don't go belly up at the same time. It's also important to realize, if your company is so bad, yet getting so many contracts, how bad could those other companies actually be? The answer is: really, really bad. Fortunately, the IT industry as a whole has convinced the entire world it needs to 'go digital' or their competitors are going to beat them to the market with their 'data analytics.' While it's probably true for many businesses, I think the vast majority is companies wanting to appear cool and hip.
taeric 8y ago
I think some of the earlier usages of this blurred things because the users were the developers in many ways. Emacs, for example, had a fun anecdote about how they had basic manuals for their secretaries teaching them lisp.[1] That is, even non-developers were empowered by the same tools as developers. That said, I can't but agree with your point and the premise. Worse, how many technological waves today have an implicit "and then migrate all current users" that is completely ignored by the team/developer? [1] https://www.reddit.com/r/emacs/comments/3tj71x/even_office_secretaries_learn_lisp_why_do_the/ https://www.reddit.com/r/emacs/comments/3tj71x/even_office_s...
xanderjanz 8y ago
Russ, whats the value of UX on products that don't exist yet? DevEx is the egg that creates the UX chicken. I love your attention to UX, but clearly developer experience is above user experience in simply a chronological sense.
- xenadu02 8y ago
  I'm not making that argument, though that is often the reaction I get. My argument is that you should understand when you're choosing to compromise the user experience, why, and how compromised it is. For example, you should know roughly how much worse the user's battery life is because of your decision. That makes the decision an informed one, based on your goals, budget, time to market, and so on. To claim a decision born of necessity comes with no compromises is delusion. That delusion might not kill you but it points toward muddled thinking. That's dangerous at the best of times, doubly so for a startup.
  - xanderjanz 8y ago
    Yep. UX is our jobs (as devs), it should be our main focus and sacrifices of it made minimally. For better or worse, does seem the days of Apple engineers working weeks on perfecting an animation behavior are largely over.
- pnloyd 8y ago
  This is such an interesting counter point. So really there needs to be a balance in tool choice that finds an optimum between deliverable UX with enough devX so that devs can stay sane enough to get the product built in the first place so the UX can exist. Surely we're not going to start making arguments that out ultimate UX delivered apps are hand written asembly (at the most absurd end of the argument ;-) )
skybrian 8y ago
It seems to me that the article is written from the perspective of someone working for a global, consumer-focused business (or aspirations to become one), without much acknowledgement that other organizations have different needs. For many businesses, it's okay not to sell to everyone. You can sell an Android or iPhone-only app, even though that leaves many people out. You can sell games that only work on some platforms. Sometimes it's okay to sell to businesses assuming they're office workers with desktop browsers and fast connections. You might not have to support multiple languages or international sales. And so on. These things are neither necessary nor sufficient for some forms of success. Of course there are other organizations that do need to do these things.

linuxftw 8y ago

We live in a world of 'ship MVP, gather customers, exit' Of course the developer experience is going to be front and center, when you're trying to start a new product and don't want to invest actual money into it for real developers, you need something quick and dirty to move the project along. I'm firmly in the camp that javascript 'webapps' are crap and make the web less web-like, the web I came to enjoy. I reluctantly admit that the ship has sailed and I enjoy the web less now.

chillacy 8y ago
Customers are somewhat complicit too, by choosing buggy products with more features over stable products with less. It turns out having a buggy product is still more desirable than not having the product at all. Also if asked to put a price on stability or performance... I suspect that number is going to be smaller than necessary.
- linuxftw 8y ago
  I think the take away lesson is: Don't write great software, have a great sales team. At least, that seems to be the sentiment of all the failure stories posted around these parts.
  - TheHegemon 8y ago
    Working in enterprise software I unfortunately agree with that statement. Our product is terrible and yet we can signing all of these giant contracts. It is a bit disheartening to realize as long our stuff "almost works" and we keep pushing out features then we will keep growing.
    - linuxftw 8y ago
      > Our product is terrible and yet we can signing all of these giant contracts. It is a bit disheartening to realize as long our stuff "almost works" and we keep pushing out features then we will keep growing. If you have an enterprise support model for your product, client turnover would be a leading indication of how successful the software really is. High renewals and good margin is a successful software product. Whether or not the companies that buy it are completely wasting their money doesn't seem to matter much as long as they all don't go belly up at the same time. It's also important to realize, if your company is so bad, yet getting so many contracts, how bad could those other companies actually be? The answer is: really, really bad. Fortunately, the IT industry as a whole has convinced the entire world it needs to 'go digital' or their competitors are going to beat them to the market with their 'data analytics.' While it's probably true for many businesses, I think the vast majority is companies wanting to appear cool and hip.

taeric 8y ago

I think some of the earlier usages of this blurred things because the users were the developers in many ways. Emacs, for example, had a fun anecdote about how they had basic manuals for their secretaries teaching them lisp.[1] That is, even non-developers were empowered by the same tools as developers. That said, I can't but agree with your point and the premise. Worse, how many technological waves today have an implicit "and then migrate all current users" that is completely ignored by the team/developer? [1] https://www.reddit.com/r/emacs/comments/3tj71x/even_office_secretaries_learn_lisp_why_do_the/ https://www.reddit.com/r/emacs/comments/3tj71x/even_office_s...

xanderjanz 8y ago

Russ, whats the value of UX on products that don't exist yet? DevEx is the egg that creates the UX chicken. I love your attention to UX, but clearly developer experience is above user experience in simply a chronological sense.

xenadu02 8y ago
I'm not making that argument, though that is often the reaction I get. My argument is that you should understand when you're choosing to compromise the user experience, why, and how compromised it is. For example, you should know roughly how much worse the user's battery life is because of your decision. That makes the decision an informed one, based on your goals, budget, time to market, and so on. To claim a decision born of necessity comes with no compromises is delusion. That delusion might not kill you but it points toward muddled thinking. That's dangerous at the best of times, doubly so for a startup.
- xanderjanz 8y ago
  Yep. UX is our jobs (as devs), it should be our main focus and sacrifices of it made minimally. For better or worse, does seem the days of Apple engineers working weeks on perfecting an animation behavior are largely over.
pnloyd 8y ago
This is such an interesting counter point. So really there needs to be a balance in tool choice that finds an optimum between deliverable UX with enough devX so that devs can stay sane enough to get the product built in the first place so the UX can exist. Surely we're not going to start making arguments that out ultimate UX delivered apps are hand written asembly (at the most absurd end of the argument ;-) )

skybrian 8y ago

It seems to me that the article is written from the perspective of someone working for a global, consumer-focused business (or aspirations to become one), without much acknowledgement that other organizations have different needs. For many businesses, it's okay not to sell to everyone. You can sell an Android or iPhone-only app, even though that leaves many people out. You can sell games that only work on some platforms. Sometimes it's okay to sell to businesses assuming they're office workers with desktop browsers and fast connections. You might not have to support multiple languages or international sales. And so on. These things are neither necessary nor sufficient for some forms of success. Of course there are other organizations that do need to do these things.