The structure of the program should exactly follow the structure of the problem. Each real world concurrent activity should be mapped onto exactly one concurrent process in our programming language. If there is a 1:1 mapping of the problem onto the program we say that the program is isomorphic to the problem.

It is extremely important that the mapping is exactly 1:1. The reason for this is that it minimizes the conceptual gap between the problem and the solution. If this mapping is not 1:1 the program will quickly degenerate, and become difficult to understand. This degeneration is often observed when non-CO [concurrency-oriented] languages are used to solve concurrent problems. Often the only way to get the program to work is to force several independent activities to be controlled by the same language thread or process. This leads to an inevitable loss of clarity, and makes the programs subject to complex and irreproducible interference errors.

Joe Armstrong, Making reliable distributed systems in the presence of software errors

Fail, fast

Adapted from an internal p2 post.

Fail-fast is a systems design approach that intentionally fails early and visibly. The gist is that it is better for users as well as better for developers to halt a system if it finds itself in a “critical enough” situation.

Wait, What, Why?

There are worse things than a crash.

Mike Stall (via Jeff Atwood) sketched an “app health hierarchy” which looks thusly:

1) Application works as expected and never crashes.
2) Application crashes due to rare bugs that nobody notices or cares about.
3) Application crashes due to a commonly encountered bug.
4) Application deadlocks and stops responding due to a common bug.
5) Application crashes long after the original bug.
6) Application causes data loss and/or corruption.

Complex systems can reduce their exposure to the darkest parts of that hierarchy in failing fast. Users are immediately presented truth rather than sometime later discovering their actions didn’t take. Developers get immediate, direct feedback in critical scenarios that points directly toward the root cause.

And, perhaps most importantly, halting in the right places prevents on-going corruption, which is what keeps me up at night as a software developer.

We can’t just BSOD our users!

Yes and no.

Yes, we can, if the situation is that critical and we know of no way to recover.

No, we can’t, on anything less than that.

Fail-fast requires (team) wisdom in implementation. Each situation must be considered in its own context. Tricky, at times, but in my experience the effort is very much worth it.

Joel Salatin Programming

…we respect and honor the pigness of the pig and the chickenness of the chicken.

Joel Salatin

Joel Salatin is an innovative farmer / agricultural philosopher(!) who has inspired me personally for quite some time. One of his farming tenets is respecting the inherent nature of the animals and the environment under his care. That resonates with me deeply. And I think it applies to programming.

We need to vigilantly avoid forcing logic against the grain of a language or its associated culture. Instead of asking “can I do this in language X?”, we need to be asking “should I do this in language X?” all along the way.

Because it’s never as simple as just writing logic a new way. Before writing that magical brilliant code in language X derived from paradigm Y, we need to ask ourselves questions like:

  • Does the logic mesh with the language’s natural expressivity?
  • What is the readability cost?
  • What are the context switching costs? Relative to rest of the project codebase? Relative to the rest of an organizational codebase?
  • What are the dev onboarding costs in deviating from community expectations?
  • Is the approach likely to be sustainable over time? Or will the magical library that makes it all possible flame out quickly?

Switched to Colemak

We have over 20 alternative layout keyboardists at Automattic circa this post, including one rather well known one. For three years, I resisted their proselytizing as I calculated the cost/benefit ratio to be against switching:

  • We live in a QWERTY world. I didn’t like the idea of being “that guy” when I sat down in front of someone else’s computer.
  • I didn’t want the hassle of radically shifted keyboard shortcuts.
  • I thought it generally over optimizing (for most people). Sixty or seventy words per minute seemed fine to me as it ought to keep pace well enough with most mental threads.

I ended up changing my mind because:

  • It’s not about the (potential) speed. I work at a keyboard the majority of my waking hours. My chances of eventual RSI are high and QWERTY doesn’t help. I’ve finally gotten through my thick head that the main benefit of an alternative layout is comfort and hopefully injury prevention.
  • The advent of the BYOD trend has made the “QWERTY world” problem less of an issue.
  • The Colemak layout leaves the main QWERTY shortcuts intact.

Most of my coworkers switched to Dvorak. I’ve switched to Colemak as I think it to be a tad more efficient. The important takeaway, IMO, is to get off QWERTY as either should be leaps better on your wrists over time.

If you are intrigued, join me in making a Colemak switch! You can grab the purdy-fied Colemak printout you see above from my coworker Matt Wiebe‘s site as a PDF.

Yes, I did type this post up in Colemak. As I’m only a couple days in, it took me, erm, awhile.

CSS Baby Steps

I was just starting to drive when I last dabbled in web UI. CompuServe was dying. AOL was about to go all-you-can-eat unlimited. My website development efforts were centered around Star Wars subjects, and CSS was nowhere near to be seen. Want to change a font?

<font color=#urfav>hooray!</font>

CompuServe
Ahh, CompuServe. You rocked my world...
until I rocked mom and dad's credit bill.

To start rectifying the situation, I decided to setup a CSS test blog here at WordPress.com.

**WARNING: put on some sunglasses**
http://hewsandbox.wordpress.com/

A few n00blet notes from the experience:

  • I think it’d be easier to play with CSS from scratch. As the blog is hosted here at WordPress.com, I only had control over the styling sheets and had to make do with the HTML as given.
  • Sandbox theme specific learning of the day: The sidebars are named that for a reason. No, you cannot move the sidebars usefully below the #content area. That’s called the #footer.
  • I wouldn’t choose blinding yellow again–especially with paint splotches. The paint really pops off dark background, but dark (and white) is so overdone. It appears there is a good reason why. I took a gamble and I seem to have generated a good stub for a future taxicab site.