Link tags: evaluating

29

sparkline

Prioritising Requirements | Trys Mudford

Over the past few years, I’ve given quite a few workshops and talks on evaluating technology. This methodical approach to evaluation and prioritisation from Trys is right up my alley!

In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.

Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.

I feel like there’s a connection here to having good design principles—the kind that explicitly value one facet over another.

Software and Home Renovation | Jim Nielsen’s Weblog

Lessons for web development from a home renovation project:

  • Greenfield Projects Are Everyone’s Favorite
  • The Last Person’s Work Is Always Bewildering
  • It’s All About the Trade-Offs
  • It ALWAYS Takes Longer Than You Think
  • Communication, Communication, Communication!

And there’s this:

You know those old homes people love because they’re unique, have lasted for decades, and have all that character? In contrast, you have these modern subdivision homes that, while shiny and new, are often bland and identical (and sometimes shoddily built). node_modules is like the suburbia/subdivision of modern web development: it seems nice and fancy today, and most everyone is doing it, but in 30 years everyone will hate the idea. They’ll all need to be renovated or torn down. Meanwhile, the classical stuff that’s still standing from 100 years ago lives on but nobody seems to be building houses that way anymore for some reason. Similarly, the first website ever is still viewable in all modern web browsers. But many websites built last year on last year’s bleeding edge tech already won’t work in a browser.

2019 End-of-Year Thoughts Archives | CSS-Tricks

I’m really enjoying this end-of-the-year round-up from people speaking their brains. It’s not over yet, but there’s already a lot of thoughtful stuff to read through.

There are optimistic hopeful thoughts from Sam and from Ire:

Only a few years ago, I would need a whole team of developers to accomplish what can now be done with just a few amazing tools.

And I like this zinger from Geoff:

HTML, CSS, and JavaScript: it’s still the best cocktail in town.

Then there are more cautious prognostications from Dave and from Robin:

The true beauty of web design is that you can pick up HTML, CSS, and the basics of JavaScript within a dedicated week or two. But over the past year, I’ve come to the conclusion that building a truly great website doesn’t require much skill and it certainly doesn’t require years to figure out how to perform the coding equivalent of a backflip.

What you need to build a great website is restraint.

The Real Dark Web

Charlie’s thoughts on dev perception:

People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.

Design tools are holding us back

My main concern about this new generation of tools is that they require a specific toolchain in order to function. “If you just use this version of React and just use this styling library and configure things in exactly this way, your designers can play around with coded components.” It worries me that teams would end up choosing (and subsequently holding onto) specific tools not because they’re the best choices for our users but because the designers’ and developers’ workflow depends on a specific toolchain to work properly.

Interview with Kyle Simpson (O’Reilly Fluent Conference 2016) - YouTube

I missed this when it was first posted three years ago, but now I think I’ll be revisiting this 12 minute interview every few months.

Everything that Kyle says here is spot on, nuanced, and thoughtful. He talks about abstraction, maintainability, learning, and complexity.

I want a transcript of the whole thing.

Interview with Kyle Simpson (O'Reilly Fluent Conference 2016)

Disenchantment - Tim Novis

I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.

The Technical Debt Myth

In some cases, it’s entirely valid to explore new products and technologies, but in others, our striving for novelty becomes the driving factor for abandoning perfectly suitable solutions under the umbrella of technical debt.

Just because a technology is a few years old and possibly frustrating in some cases doesn’t mean you’re in technical debt. We need to stop projecting our annoyances as pitfalls of technological or design choices.

You probably don’t need that hip web framework - Charged

This is a bit ranty but it resonates with what I’ve been noticing lately:

I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.

Simple & Boring | CSS-Tricks

Let’s take a meandering waltz through what other people have to say about simplicity.

The “Backendification” of Frontend Development – Hacker Noon

Are many of the modern frontend tools and practices just technical debt in disguise?

Ooh, good question!

On Simplicity | Max Böck - Frontend Web Developer

We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process we create another layer of complexity that, in turn, causes its own set of issues.

The Principle of Least Power looms large over this:

Some of the most important things in the world are intentionally designed “stupid”. In any system, the potential for error directly increases with its complexity - that’s why most elections still work by putting pieces of paper in a box.

Building a Progressively-Enhanced Site | Jim Nielsen’s Blog

This is an excellent case study!

The technical details are there if you want them, but far more important is consideration that went into every interaction. Every technical decision has a well thought out justification.

“Evaluating Technology” by Jeremy Keith – An Event Apart video on Vimeo

This is a recording of my Evaluating Technology talk from An Event Apart in Denver just over a year ago. This was the last time I ever gave this talk, and I think you can tell that the delivery is well-practiced; I’m very happy with how this turned out.

In this 60-minute presentation recorded live at An Event Apart Denver 2017, Jeremy Keith helps you learn to evaluate tools and technologies in a way that best benefits the people who use the websites you design and develop.

Salty JavaScript analogy - HankChizlJaw

JavaScript is like salt. If you add just enough salt to a dish, it’ll help make the flavour awesome. Add too much though, and you’ll completely ruin it.

Breaking the Deadlock Between User Experience and Developer Experience · An A List Apart Article

Yes! Yes! Yes!

Our efforts to measure and improve UX are packed with tragically ironic attempts to love our users: we try to find ways to improve our app experiences by bloating them with analytics, split testing, behavioral analysis, and Net Promoter Score popovers. We stack plugins on top of third-party libraries on top of frameworks in the name of making websites “better”—whether it’s something misguided, like adding a carousel to appease some executive’s burning desire to get everything “above the fold,” or something truly intended to help people, like a support chat overlay. Often the net result is a slower page load, a frustrating experience, and/or (usually “and”) a ton of extra code and assets transferred to the browser.

Even tools that are supposed to help measure performance in order to make improvements—like, say, Real User Monitoring—require you to add a script to your web pages …thereby increasing the file size and degrading performance! It’s ironic, in that Alanis Morissette sense of not understanding what irony is.

Stacking tools upon tools may solve our problems, but it’s creating a Jenga tower of problems for our users.

This is a great article about evaluating technology.

The Amish understand a life-changing truth about technology the rest of us don’t — Quartz

The headline is terrible but this interview is an insightful look at evaluating technology.

I remember Kevin Kelly referring to the Amish as “slow geeks”, and remarking that we could all become a little more amish-ish.

It’s not that the Amish view technology as inherently evil. No rules prohibit them from using new inventions. But they carefully consider how each one will change their culture before embracing it. And the best clue as to what will happen comes from watching their neighbors.

Jeremy Keith on your content, failing well, and the Indie Web Movement - YouTube

I had a chat with some people from Name.com while I was in Denver for An Event Apart. Here’s a few minutes of me rambling on about web development and the indie web.

Jeremy Keith on your content, failing well, and the Indie Web Movement

Jeremy Keith on Evaluating Technology at SmashingConf Barcelona 2017 on Vimeo

I think this is the best delivery of this talk I’ve ever given. It was something about being in that wonderful venue.

I got quite worked up around the the 32 minute mark.

Mozilla Developer Roadshow Asia Jeremy Keith - YouTube

At the 14 minute mark I had to deal with an obstreperous member of the audience. He wasn’t heckling exactly …he just had a very bad experience with web components, and I think my talk was triggering for him.

Mozilla Developer Roadshow Asia: Jeremy Keith