
Principles and priorities - hypertexthero
https://adactio.com/journal/16811
======
simonw
The thing that confuses me about "modern", JavaScript-everything web
development is that I just don't see the developer efficiency, at all.

I've collaborated with many different teams that use the modern JavaScript
stack. It seems to me that it takes multiples of time to deliver features
compared to the old forms-and-HTML-with-a-tiny-bit-of-JavaScript-enhancement
methodology.

Are we really optimizing for developer efficiency here? We've given
JavaScript-everything a decade to prove that it's a better, more productive
way of building higher quality websites and applications. I don't think it
has.

~~~
stickfigure
Your experience does not match mine.

I worked through the pre-Javascript world, the jquery world, the angular1
world, and now the react world (not to mention a decade of native GUI
development before that). I am _vastly_ more productive with react and my UIs
are much easier to use.

Every time I submit some 1990s or 2000s era form that gives me an error
because I typed some field wrong, but also wipes out half the other fields I
spent 15 minutes typing... and of course, hitting the back button wipes out
the remaining fields... I want to reach into the screen and throttle someone.

No thanks.

~~~
samastur
None of the problems listed is inherent in HTML + touch of JS. Especially
since most browsers these days will remember what you typed anyway unless
specifically instructed otherwise. Complaining about the back button behavior
in SPA world seems...misplaced? If anything, its behavior is even worse.

~~~
andrewla
I think this is referring to the server round-trip -- form submit, server-side
validation, "you have to specify a color for your widget" and everything on
the field is blanked out because the server didn't fill in the default values
into the form based on your previous submission.

Back button stuff; I mean, it's not trivial to support it correctly now, and
it might just be an increased focus on usability and testing of this sort of
thing, but hitting back was always dicey -- half the time you'd get some error
about re-posting form data when you hit back, and if you said no, bad things
happened, and if you said yes, worse things happened.

~~~
winkeltripel
> it's not trivial to support it correctly

Back button works every time if you create pages, and navigate between them
using links.

There are some garbage web forms out there, but if we're comparing building
SPA in 2020 or webforms in 2020, webforms is unlikely to screw up your back
button.

------
jasode
Developer efficiency often gets prioritized over user experience _because that
's the only way the software would even get to exist_.

I take my own software that I write solely for personal use as examples. In
those cases, I play both roles of the developer and the end user. Most of my
utilities are _console command line_ utilities instead of full GUI. As a
result, I have a bunch of command-line utilities that are very cumbersome to
use. That's because I prioritized the dev experience over the UX.

Console apps are 10 times faster to code. I can bang out printf() or
Console.WriteLine() statements 10x faster than placing GUI textboxes on a
form. Yes, GUI wizards and templates accelerate the layouts but it's still not
as fast as console apps for quick & dirty utilities. As an end user, I'd
prefer easier-to-use GUI apps but I don't have the extra time to code them. I
complained to the developer (that's me) to make a GUI app with better UX
instead but the dev ignored me.

With my limited time, I'd rather have 20 utilities with bad UX that _exist_
rather than just 5 apps with good UX at the expense of not having the other 15
at all. It's an unavoidable tradeoff of finite time.

Likewise, I as an end user don't like Electron apps but I know that lecturing
developers on using something lighter weight like C++ & Qt or C#/Winforms
means they _wouldn 't bother writing the app at all_. It was the ease (and/or
familiarity) of Javascript that allowed them to write the app in the first
place.

[REVISED above text to clear up the misunderstanding in the reply.]

~~~
cml
Is it possible you are agreeing with the author?

> Most of my utilities are console command line utilities instead of full GUI
> and they are very cumbersome to use. That's because I prioritized the dev
> experience over the UX.

As the user you prefer command line utilities, and so I interpret your
building command line utilities as prioritizing the user's experience.

On the other hand, if you needed a program that could exist very efficiently
as a command line utility but, desiring to learn how to use some new GUI
toolkit you built a GUI instead, I might interpret your action as prioritizing
the developer experience (in which you are focused on the details of the
implementation) over the user experience (in which you are focused on the
results).

~~~
intarga
You misunderstood that line, they're saying the command line utilities are
cumbersome

~~~
a1369209993
> the command line utilities are cumbersome

Except this is obviously untrue? I can't pipe a _window_ through grep or sed.

~~~
onemoresoop
When you need to. Other times when you need to pass lots of params and havent
decided which ones are staying so scripts are a bit extra time which is not
there and when you need to explore in a different way the domain area, GUIs or
TUIs may be more suitable. I love what one can do out of simple tools like
that and how nicely they compose but if the experience is draining, my brain
is going to notice and start avoiding it next time

------
partyboat1586
Developer efficiency is actually harmed by valuing it so much. Developers get
into pointless ideological debates about purity and that hurts their
efficiency. When good developers have to deliver features in a short time
frame they stop debating that stuff and make decisions. They then learn from
these decisions the hard way and no one is having an ideological debate any
more.

~~~
agentultra
And if they keep delivering features in short time frames they will never get
a chance to debate quality or elegance in their work.

And eventually you will start hearing them complain about an unmaintainable
mess and turnover will probably increase.

/s

I think you do have to care, on some level, about maintaining code quality and
standards. I've worked in feature-factories and it's not a panacea. _It doesn
't crash_ and _it goes reasonably fast_ are both features after all that seem
to be related to the quality of a code base and the expertise of the team
behind it.

~~~
jakear
One approach is a schedule for when everyone works on debt vs features vs
testing.

For instance: first week of the iteration is for paying off debt. Second and
third are feature work. Fourth is testing (note: not unit testing, real
testing. As in everybody chips in to actually play around with the features
their colleagues added and provide feedback; also verify that all the bugs
that were fixed this iteration didn’t creep back in, or get fixed with a
“works on my machine” patch)

------
MattGaiser
1\. Most developers don't work for the end-user. They work for who is paying
their salaries, which is often someone is mostly interested in luring the end
user and using them to sell a product to someone else (everyone from Google to
Facebook to DoorDash has this model). Without those megabytes of JS analytics
and whatnot, the end-user cannot be packaged into the actual company product.

2\. As the real customer for the developers consists of these institutions,
they care more about development costs than whether customer internet is
wasted. Developer convenience means cheaper projects.

3\. Users blame themselves for the performance tax. They think they downloaded
a virus, have an old computer, or need faster internet and they go and upgrade
all those things, making the performance tax seemingly disappear.

~~~
askafriend
> Most developers don't work for the end-user.

This is extremely reductionist.

If you want to take it further, then nobody works for the end user ever. If
you have any funding _at all_ (even from the public markets) then you "work
for investors".

Can you see how this is theoretically true, but practically not as true?

~~~
joefourier
But it does explain a lot of things in practice. Many developers will choose
to use a technology not because it makes the end-product better for the end-
user, but because it will make their resume more attractive for potential
employers.

~~~
andrewingram
I don’t doubt that these developers exists, but I’ve never knowingly met one
in 13 years of full time dev work.

------
dang
The submitted title ("Developer efficiency prized above all else") broke the
site guidelines, which ask: " _Please use the original title, unless it is
misleading or linkbait; don 't editorialize_"
([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)).
Cherry-picking the detail you think is most important from an article is
editorializing.

Like it or not, titles dominate discussion. The comments in this thread are
nearly entirely a reaction to that title. The HN guidelines specifically ask
users not to abuse that power. On HN, submitting an article doesn't confer any
special right to frame it for everyone else.

If you want to say what you think is important about an article, please post
it as a comment to the thread. Then your view will be on a level playing field
with everyone else's:
[https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%22level%20playing%20field%22&sort=byDate&type=comment)

If it's necessary to change a title, please do that by picking the most
neutral and accurate phrase you can find on the actual page which represents
what the article is about. More on that here:
[https://news.ycombinator.com/item?id=22932244](https://news.ycombinator.com/item?id=22932244)

------
franciscop
There's a big unspoken truth with Javascript here. The _vast majority_ of Open
Source Javascript is created by developers for no money to solve their own
problems and itches. Maybe not the most visible top-level libraries like
React, but the thousands of dependencies are there to help the developer with
some issue they had at some point. Sure they may have secondary goals, some of
them including being time efficient, or memory efficient, or size efficient,
etc.

So it seems expected that the agglomeration of tools with varying secondary
goals, and a clear primary goal, results into this goal of developer
efficiency being potentiated greatly. Forget about writing 5 lines of code,
just npm install it.

And that _is fine_ IMHO, people/companies with different goals should be doing
things differently. It also seems that turnover is a big issue as well for
most companies, so they also try to make dev experience better!

------
stx
In my experience, companies expect developers to output features quickly. When
it does not happen as quickly as expected the assumption is that its the
developers when often times its the overall organizations process that is a
mess. Its not necessarily a technology problem but a people problem.

~~~
onemoresoop
People also create technology or adopt technology because of people, most of
the time. You have a point there with messy organziations, but that is not
mutually exclusive with the software stack, usually up to date with the
fashion. And it is amusing that older technology almost always can get the job
done okay and efficiently only because its problems are already known and
there are already boring but understood worksarounds. Yes, boring but works.
Versus cool and solves this problems but causes other new problems we know
nothing about. It’s been so far just like a game of whackamole

------
mrfredward
Software development doesn't exist in a vacuum. The author talks about these
design principles as if they are supposed to satisfy the software team's
personal values, when in reality it needs to be more about the organization's
goals and values. Take this statement:

>Usability is more important than profitability.

For a bootstrapped company in danger of running out of money, it's ridiculous
to prioritize perfecting UX over making sales. For an open source team,
profitability isn't part of the equation at all but user experience might be a
top priority. My point is, these aren't just matters of personal taste, the
"design principles" have to mesh with the rest of the organization.

------
Erwin
Going one level up to
[https://adactio.com/journal](https://adactio.com/journal) shows a sparkline
(with author's activity perhaps, the latest posting is entry 2666!) which has
a feature I have never seen before: an audible graph. Clicking on the
sparkline plays tones matching the data. Not particulary useful, but make me
thing about using audio for presenting data (apparently "sonification" is a
thing!)

------
imbusy111
You're talking about values, not design principles.

------
a1369209993
Similarly: "Make it work, make it right, make it fast, make it pretty, _in
that order_."

~~~
onemoresoop
Make it work now and fast potentially has maintainability issues down the
line. Make it maintainable and brautiful may miss the mark on what’s actually
needed and may be overengineered. Somewhere in between there is a sweet spot
that can be found by luck or with some planning, a POC, etc

------
bconnorwhite
Short term: user experience, even over developer experience, because user
experience is the point of developer experience.

Long term: developer experience, even over user experience, because over a
long enough time period developer experience drives user experience.

------
jdbernard
I think there is some truth to the conclusion. But remember that developer
time is by far the largest expense when creating software. Sometimes the focus
on developer efficiency is driven primary by a desire to minimize this cost.

------
polote
> Sadly, I think the current state of “modern” web development reverses that
> principle. Developer efficiency is prized above all else.

I strongly disagree with that, "modern" web development values beautiful code
over almost anything else, if that wasn't the case you could have one of your
dev building a form in a few hours, instead they need tons of tools (react for
example) that slow their development

~~~
0xDEEPFAC
Yea, the idea that "modern web programming" is beautiful at all franky makes
me cringe.

Web programming and the web has separated developers too far from the hardware
that actually runs the stuff and, as a result, we have built confusing towers
of babel.js.

I mean, Javascript was originally made for developer ease over user
reliability - and look at it now - it shows with the cacophony of NPM
dependencies prone to "leftpad" style failures and the new frameworks every 6
months. All of this, of course, goes against one of the author's key points:
"User experience, even over developer experience."

Unfortunately, I don't think the problem is solved by process but instead on
re-education to compiled, reliable systems, made with a typing system designed
to catch errors. Introducing more process and efficiency will never make a
bicycle into a proper car.

~~~
Tade0
> I don't think the problem is solved by process but instead on re-education
> to compiled, reliable systems, made with a typing system designed to catch
> errors.

We already have that in the form of TypeScript, but both left-pad and core-js
were, for lack of better term, non-technical failures.

Only the most recent such case - is-promise - was purely a technical failure.

There's not much than can be done when the sole core maintainer of a popular
library lands in a penal colony.

~~~
0xDEEPFAC
> We already have that in the form of TypeScript

While an improvement Typescript is a far cry from the likes of Ada and doesn't
really compare.

> There's not much than can be done when the sole core maintainer of a popular
> library lands in a penal colony.

Perhaps the solution is to not use Javascript, since it always forces you into
an "ecosystem" of "frameworks" at every turn - and they are not cheap! Just
another thing to throw on the stack. mb's be damned.

~~~
Tade0
> While an improvement Typescript is a far cry from the likes of Ada and
> doesn't really compare.

Given their respective popularities perhaps the point of diminishing returns
was crossed somewhere?

> Perhaps the solution is to not use Javascript, since it always forces you
> into an "ecosystem" of "frameworks" at every turn - and they are not cheap!
> Just another thing to throw on the stack. mb's be damned.

This is becoming outdated information thanks to the likes of Svelte:

[https://svelte.dev/](https://svelte.dev/)

and Solid:

[https://github.com/ryansolid/solid](https://github.com/ryansolid/solid)

------
throwaway55554
Here's the TL;DR.

> But as a general principle, I think this works:

> User experience, even over developer experience.

>Sadly, I think the current state of “modern” web >development reverses that
principle. Developer efficiency >is prized above all else.

~~~
ehnto
I probably complain about this too much, websites built with SPA technologies
can very often behave poorly to the user. Jittery, slow to be useful,
generally less performant than other solutions. I feel like that gets ignored
because so many people want to be on the bandwagon, and many feel the
developer experience is better so we just kind of sweep that part of UX under
the rug.

------
craigkerstiens
The TLDR states that the current state of modern development prioritizes
developer efficiency over all else, and that user experience is way under
valued.

My problem with this isn't that it places value on user experience, it is in
the premise that developer efficiency is prized above all else. Deploying an
app today is just as hard as it was 15 years ago. The only two things that
jump out in recent memory that made a very sizable difference on developer
experience were Heroku, Github, Docker. Setting up a hello world with react
and a basic API takes me a day or more, where as 10 years ago with jquery this
was an hour or so. Deploying an app with K8s is google scale, but takes me a
week to do, forget debugging something in production.

If we've been prioritizing developer efficiency at all costs we've failed
pretty massively. I personally love the idea of optimizing a lot for developer
efficiency because we can do deliver more value to others at the end of the
day, but there's a lot of shiny new stuff that has some reason for existing
which is definitely not developer efficiency.

~~~
ThrowawayR2
> " _If we 've been prioritizing developer efficiency at all costs we've
> failed pretty massively._"

Do we not hear all the time on HN, for example, that "Yeah, native apps are
more efficient and look better but Electron lets us just write it once and
deploy on multiple platforms"?

~~~
joefourier
Electron allows you to package your webapp into a downloadable stand-alone
package, but does not make your development any more or less painless if you
decide to use modern Javascript frameworks and infrastructure built for
Google-scale deployment.

------
ncmncm
Operating system policies are interesting in this regard.

Continued correct activity of OS processes is prioritized over user-level
activities even where the purpose of the system is explicitly the latter. The
reasoning seems to be that if the OS can't keep up, it can't maintain the
environment that enables user-level stuff to work.

This generates conflict where user-level activities have real-time
requirements. It is very, very hard to get your typical OS to leave a process
running on a dedicated ("isolated") core and never, ever interrupt it, even
given root privileges and boot-time static provisioning. Just store a byte in
a file-mapped page, and whoops! get unsynced millisecond pauses while the OS
copies it to the disk sector. Oh, and surely you still wanted an interrupt
every millisecond to see if any OS resources tied to the core need cleanup,
even though it never is asked for OS work.

~~~
jschwartzi
Which OS? In QNX this isn't an issue. If you have hard real-time requirements
you need to use a Real-Time Operating System.

~~~
ncmncm
Since when is QNX a typical OS?

Most programs need to run on the OS they need to run on, and on the hardware
they need to run on. QNX (or other favorite obscurity) most usually is not an
option.

