Donations Make us online
Back in October of 2011 Ryan Dahl wrote a blogpost
entitled “I hate almost all software” in
which he asserts:
The only thing that matters in software is the experience of the user.
I totally agree with this statement, but I believe that it has broader
implications than Ryan’s suggesting.
At a previous employer, I was asked to add a single checkbox and label to the
contents of a popover. When asked how long this would take, I considered that
the logic for that part of the app was in a Backbone view that was over 1,000
lines long and it extended another Backbone view that was over 2,000 lines long.
I estimated it would take a week, and the PM was horrified. What’s worse is it
actually took closer to three weeks. 😱
Why did it take so long? The code was unmaintainable. I was able to add the
checkbox easily enough, but getting the data from the checkbox to update the
model was a nightmare. If that wasn’t enough, the number of bugs I introduced
with my hacky example was frightening because (of course) those files had leaky
abstractions all over the place and absolutely no tests.
Now, consider if the component had been built with
SOLID programming principles
(DRY, SRP, etc. etc.). I probably could have finished that feature in a day or
less.
So did the way the app code was written impact the end user? You betcha. Did the
user care that they had to wait weeks rather than days for the new feature?
Yeah, they totally cared.
So yes, it’s true. The only thing that matters in software is the experience of
the user. We created computers to improve our lives, and if the software we’re
using doesn’t do that then it’s failed.
The experience of the user is indirectly, but strongly coupled to how we build
software
So the big question: Does it matter to the user that we’re using the latest JS
framework, build tool, const vs. let, semicolons, tabs, a git merging strategy,
or a specific deployment service? Of course not!
Our measure of success should be how well we deliver what the user wants (and
no more). Our choice of tools should be based on that fundamental goal.
At the same time, the latest tech and a good UX are not mutually exclusive. The
latest and greatest technology can be a great way to accomplish this goal.
So why does this matter?
We waste time endlessly debating minutiae that has little impact — whether we
should use semicolons in our JavaScript (no), or how many spaces to use for
indentation (two), but we should instead focus on the tech choices that make a
significant impact: solid design patterns, linting (only good rules please),
testing, continuous integration, delivery, and deployment. These choices are the
basis for an app that delivers a quality user experience. A great app is never
truly finished. Requirements change, and our choices as developers determine how
easily and quickly we are able to deliver new features, while keeping the
product as polished as possible.
Optimize for change.
So yes, our users don’t really care how we build our application, or what
abstractions we use in doing so. Remember that we use JavaScript and the web
because, with them, we can deliver an awesome experience to the user who doesn’t
want to download, install, and regularly update our app. If we found another
solution to accomplish that better, we’d all jump ship.
User Experience includes a lot more than just base functionality. How your
application is written, built, and deployed can make a big difference.
The real takeaway for you here is that you should be intentional about what you
spend your time arguing about. Behind every opinion you hold firm, make sure
your opinion is founded upon what’s best for the people using your software. If
it’s not (or if that connection is tenuous), it may not be worthwhile arguing
about.
I’ll just add this because I have to: Delete eslint-config-react and
eslint-config-airbnb and use eslint-config-react-app instead. Also… Use
prettier…
Big thanks to the people who helped review and edit this post, especially
Kyle Robinson for basically being the article’s
editor.
Source link
