Link tags: software

135

sparkline

Linking Manifesto – Manifesto for Ubiquitous Linking

We invite software developers to do their part, by

  1. ensuring their users can conveniently obtain a link to the currently open or selected resource via a user interface; and
  2. providing an application programming interface (API) to obtain or construct a link to that resource (i.e., to get its address and name).

Making Colophon Cards – Baldur Bjarnason

I think Baldur is onto something here with his categorisation of software. There’s the software based on innovation, something truly novel:

Innovation’s the word. Pushing the boundaries. You know the phrases. Usually spouted by that dude at the party.

Then there’s the software based on itertion, making a better version of a proven tool:

We are now in a place where we have entire genres of software that have decades of history, are backed by stacks of new and old research, have dozens of successful, well-made exemplar apps, and a broad enough conceptual space to allow for new variations on the theme.

In short, we have genre software and we have avant-garde software, and I’ve always been more interested in genre fiction than literary fiction.

Software developers have stopped caring about reliability

My web browser has been perfectly competent at submitting HTML forms for the past 28 years, but for some stupid reason some asshole developer decided to reimplement all of the form semantics in JavaScript, and now I can’t pay my electricity bill without opening up the dev tools. Imagine what it’s like to not know how to do that. Imagine if you were blind.

Folks, this is not okay. Our industry is characterized by institutional recklessness and a callous lack of empathy for our users.

The Single-Page-App Morality Play – Baldur Bjarnason

I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time.

When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts.

Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win. You usually see improvements on all of the issues mentioned above. You get the same general UX except with more reliable loading, history management, and loading features—provided by the browser.

Before you dismiss Baldur as a hater based on what I’ve just quoted, you should really read the whole article. The issue he points to is not with the technical architecture of single page apps, but with management.

Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations.

A lot of what he says really resonates with me. Over and over again I’ve seen projects where the technical decison around which monolithic client-side JavaScript framework to use has been made even before a problem has been defined.

Baldur’s conclusion chimes a lot with what I’ve been saying in conference talks this year: the biggest challenges facing the web are not technical in nature.

The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps.

It’s always humans.

Why are hyperlinks blue?

A wonderful bit of spelunking into the annals of software interfaces by Elise Blanchard.

Representation and what happened to women in Tech

Men specialized in hardware while software development was seen as an exciting alternative to secretarial work. In 1967, Cosmopolitan published an article titled The Computer Girls, encouraging young women to pursue careers in computer science. So the curve went up, and continued to do so up until 1984. That’s when personal computers appeared.

Marketing matters:

When Apple released the Macintosh 128K and the Commodore 64 was introduced to the market, they were presented as toys. And, as toys were gendered, they were targeted at boys. We can look at advertisements from that time and quickly find a pattern: fathers and sons, young men, even one where a man is being undressed by two women with the motto Two bytes are better than one. It’s more evident with the ads for computer games; if women appear, they do so sexualized and half-naked. Not that appealing for young girls, one could imagine.

Software Crisis 2.0 – Baldur Bjarnason

Baldur Bjarnason writes an immense treatise on the current sad state of software, grounded in the historical perspective of the past sad state of software.

Making Reasonable Use of Computer Resources

The paradox of performance:

This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement. Why is that?

Because we prioritise the developer experience over the user experience, that’s why:

Although our job is ostensibly to create programs that let users do stuff with their computers, we place a greater emphasis on the development process and dev-oriented concerns than on the final user product.

We would do well to heed Craig’s observations on Fast Software, the Best Software.

Hacks Are Fine / Matt Hogg FYI

If you employ a hack, don’t be so ashamed. Don’t be too proud, either. Above all, don’t be lazy—be certain and deliberate about why you’re using a hack.

I agree that hacks for prototyping are a-okay:

When it comes to prototypes, A/B tests, and confirming hypotheses about your product the best way to effectively deliver is actually by writing the fastest, shittiest code you can.

I’m not so sure about production code though.

Don’t Feed the Thought Leaders - Earthly Blog

A great tool is not a universal tool it’s a tool well suited to a specific problem.

The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them.

How to Build Good Software

The right coding language, system architecture, or interface design will vary wildly from project to project. But there are characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:

  • Reusing good software is easy; it is what allows you to build good things quickly;
  • Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
  • The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.

Understanding these characteristics may not guarantee good outcomes, but it does help clarify why so many projects produce bad outcomes. Furthermore, these lead to some core operating principles that can dramatically improve the chances of success:

  1. Start as simple as possible;
  2. Seek out problems and iterate; and
  3. Hire the best engineers you can.

The Long Now Foundation: “Nadia Eghbal Talk”

This is a great talk by Nadia Eghbal on software, open source, maintenance, and of course, long-term thinking.

Copying is the way design works || Matthew Ström: designer & developer

A people’s history of copying, from art to software.

Designers copy. We steal like great artists. But when we see a copy of our work, we’re livid.

Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY

Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of universities across the United States. Our blog posts on $PRACTICAL_OPEN_SOURCE_FRAMEWORK seemed to get fewer upvotes when posted on Reddit as well, cementing our conviction that our technology stack was now legacy code.

This is all just mwah—chef’s kiss!—perfect:

Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost.

Twitter thread as blog post: Thoughts on how we write CSS | Lara Schenck

CSS only truly exists in a browser. As soon as we start writing CSS outside of the browser, we rely on guesses and memorization and an intimate understanding of the rules. A text editor will never be able to provide as much information as a browser can.

Why is CSS frustrating? ・ Robin Rendle

CSS is frustrating because you have to actually think of a website like a website and not an app. That mental model is what everyone finds so viscerally upsetting. And so engineers do what feels best to them; they try to make websites work like apps, like desktop software designed in the early naughts. Something that can be controlled.

FontGoggles — Interactive Previewing and Comparing

A really nice open-source font-previewing tool for the Mac.

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.

Reflections on software performance - Made of Bugs

I’ve really come to appreciate that performance isn’t just some property of a tool independent from its functionality or its feature set. Performance — in particular, being notably fast — is a feature in and of its own right, which fundamentally alters how a tool is used and perceived.

This is a fascinating look into how performance has knock-on effects beyond the obvious:

It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower.

What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task.

This observation is particularly salient for web developers:

We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.