Akin's laws of spacecraft design

Back in 2003 when I was still in elementary school, Dave Akins wrote a list of laws to abide when building a spacecraft. I'm not planning to build one of those any time soon, but there seem to be many similarities with web development. A few examples:

  • Engineering is done with numbers. Analysis without numbers is only an opinion
  • Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate
  • Don’t do nuthin’ dumb

Here's a good one te keep next to your desk, and consider yourself lucky next time you ship a bug to production.

  • Space is a completely unforgiving environment. If you screw up the engineering, somebody dies

Read all 44 laws at their home on spacecraft.ssl.umd.edu.

Prioritization systems

| 3 min read

I work at an agency that started out building websites and small apps, but the past years have shifted towards larger web apps and products.

Small projects are easy to manage. GitHub issues or Basecamp todos are more than enough to keep things going. Adding a feature or refactoring a small project is also easy, because there aren't too many moving parts to take consider.

Large and especially long-living projects are constant moving targets. It's harder to estimate things and technical debt can become a real issue. A linear, chronological task list won't do it anymore, we need to start prioritizing things.

I want to share four systems that have helped me, both on a personal and team level, prioritize work on large projects.

Read more

Materials and tools

I was lucky enough to see Jeremy Keith speak at the inaugural edition of Full Stack Europe. He did a keynote on building on/for the web. I'm not going to distill the talk's content to a few paragraphs as that wouldn't do it justice, hopefully the talk will come online at some point.

One thing I'd like to mention he talked about is the difference between materials and tools for the web. Jeremy written about this in the past, and I believe his journal entry is an article worth sharing.

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

And a bit further:

I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).

Read the full article on adactio.com.

Disappointed

| 1 min read

Want to view a single image on @imgur (literally its only job)? Good luck! You gotta successfully download (354KB) and run (1.21MB) of client-side React in order to get your image requested as resource 110 of 553. What should have been an IMG element became… this.

@csswizardry - and don't forget to look at the visualization

This is ridiculous. Things like this don't even make me any mad anymore, they disappoint.

To make things worse, a large portion of the replies try to justify everything with “but business decisions…".

Nah.

We can do better. We should do better.

Takuya Matsuyama’s take on growth

Takuya’s is the sole developer and owner of Inkdrop, a popular markdown app. He wrote setting goals to make his product better instead of bigger.

I asked myself “do I really need another goal?” Because the project is just what I love to do in the first place, as I wrote in the article about grit. Making it profitable was merely a requirement to continue doing it and not a genuine source of the motivation.

I’ve been thinking about the balance between growth and sustainability lately, and this quote from the article stuck out:

By focusing not on endless growth or expansion, it makes your business sustainable. Interestingly, about 90 percent of all businesses worldwide that are more than 100 years old are Japanese. They all have fewer than 300 employees, and the ones that still exist never grow quickly or without great reason.

Read the full article on blog.inkdrop.info.

This site now supports dark mode

| 1 min read

I prefer to use light interfaces, so I rarely use dark mode in macOS or iOS. I often see people add dark mode to their sites, but never really knew whether visitors actually care. I started a Twitter poll:

Do you consider dark mode on websites / blogs (not apps) useful?

The poll is still open. At the time of writing, 225 people responded, and 47% answered “Yes”. Enough to convince me to add a dark mode to my blog.

Read more

React's versioning policy

React follows semantic versioning, but with a twist. From their versioning policy:

When releasing critical bug fixes, we make a patch release by changing the z number (ex: 15.6.2 to 15.6.3).

When releasing new features or non-critical fixes, we make a minor release by changing the y number (ex: 15.6.2 to 15.7.0).

When releasing breaking changes, we make a major release by changing the x number (ex: 15.6.2 to 16.0.0).

The twist is subtle: non-critical bugfixes are released as minor releases.

I've often wondered whether three digits really is necessary for versioning. As a package maintainer, deciding between minor and patch is often a gray area.

Two digits would suffice: breaking changes and non-breaking changes. Feature or bugfix doesn't really matter from a technical point of view: upgrading can either break things, or can't.

React reserves the patch number for critical bugfixes, which I believe is a necessary escape hatch in a two digit system. But I like I how they default to simply bumping minor versions.