found drama

get oblique

dream.20160123: through the window

by Rob Friesel

You’re fleeing the monster. Run through the city. You never see it, but you can hear it. Hear its growl. Hear the rumble of its footsteps. You hide behind buildings. Dodging. Evading. Never more than a step ahead. Sounds of destruction and carnage. But you’re running out of places to run, to hide. You make it to the last house on the island and duck inside, down into the basement. There are already so many people there huddled, looks of terror on their faces. You face your own terror. But terror isn’t hopelessness. You wade through the water in the basement to the window. Someone is trying to kick a hole through the wall. But you pry open the window. It’s too narrow to squeeze through, but you keep peeling back layers until you’re out and swimming beyond the monster’s reach, falling over the edge of the world.

Conceptual Debt: sticking with your original-but-poor design (out of fear)

by !undefined

RE: Conceptual Debt is Worse than Technical Debt

This post practically reads like advocacy for UX Architects and (more broadly) Lean UX, or some similar approach of product design with built-in idea validation. A point that particularly resonated with me was the assertion around product inertia — this idea that if you get a product out in the market, there’s a tendency for it to stay the same — even if its initial design was poor — because of the danger of alienating the customers that did stick it out and learn that original-but-poor design.

“technical debt” as shorthand for five different scenarios

by !undefined

I particularly liked the post “Towards an understanding of technical debt”, and mostly because the author is skeptical of the common thinking and conventional wisdom around the subject. The key takeaway is that when people talk about “technical debt”, they tend to conflate five different kinds of problems:

  1. Maintenance work
  2. Features of the codebase that resist change
  3. Operability choices that resist change
  4. Code choices that “suck the will to live”
  5. Dependencies that resist upgrading

He invokes Norvig’s “all code is liability” here — which is pithy and memorable, but overstates the case — but ultimately his point is: technical debt is shorthand for one of these five scenarios where our complaints are ultimately rooted in the fact that we’re taking on the perceived burden of unpleasant work — usually due to some kind of implicit resistance or inertia of the codebase. (And this dovetails nicely with Simler’s “A Codebase is an Organism” post that made the rounds recently.)

From a practical perspective, the lesson seems to be: when you start invoking the phrase “technical debt”, try to consider which of the 5 categories the scenario fits into. What kind of resistance or inertia are you facing? And how can you move things forward without resorting to “technical bankruptcy” or “papering over” the problem with an Nth-level of indirection?

search term haiku: December 2015

by Rob Friesel

wrap up your year’s end
incredible cross-sections
cherry-pick a blob

“Search Term Haiku” is a series wherein I examine this site’s log files and construct one or more haiku poems from search terms and phrases that led visitors to the site. Where possible, I attempt to keep the search phrases intact. However, as these are haiku poems, I do need to follow the rules.

dream.20151224: chimeras

by Rob Friesel

You are overrun by them. An infestation of a grotesque mouse-octopus chimera. Little black oily vermin; naked tails and little furry rumps that coalesce into a mass of writhing black tentacles. Traps can’t hold them. And as they swarm, you try to stomp them out. Black ichor runs from their wounds. But, once cut in half, they regenerate. And each severed tentacle, like the hydra, regrows two-fold. And they’re getting bigger.

Rebecca Murphey on HTTP/2

by !undefined

Recently, the venerable Rebecca Murphey wrote a post called Building for HTTP/2. The rise of HTTP/2 and what it means for building and deploying web applications (both on the front- and the back-end) is something that I’ve been curious about and following for the past couple years. As expected, Murphey’s take on the subject is thoughtful and thorough, with particular attention paid to what it means for “real world” developers. Something that she discusses in this piece which was not something I’d previously thought about was: whither the tooling for HTTP/2 applications? Her examination of the trade-offs and the “reality check” for the present day (and near-future) are also well worth the time.

dream.20151205: ephemeral itinerary

by Rob Friesel

You are sitting in a treehouse, trying to plan a trip, the two of you. You believed that you had narrowed down the destination and all you had left was to book it. But things got complicated. New suggestions came in. People kept appearing with new ideas. You couldn’t possibly do them all. Maybe over a lifetime you could, but you felt pressured to expand the scope. You tried to write down each of these ideas. To rank them, to sort them. Someone said that hey maybe the two of you could combine two of the trips? Half as much time in one spot and then move on to the next? It’s overwhelming, it’s too much. You climb up from the treehouse, up to the top of a hill, then the top of a dam. Everyone follows you. You drop your pen. Your paper blows away. Someone hands you another sheet of paper, but it’s torn from a glossy magazine. The pen is replaced with a marker. You try writing but the ink just smears. Every voice get louder. Everyone shouting over everyone else. You climb down to retrieve the original pen. You try writing the place names over again but you can’t press hard enough and the paper rips into a dozen pieces, then a hundred. The wind picks up. Water rushes over the dam.

search term haiku: November 2015

by Rob Friesel

hairy eyeball dreams
fishing trawler cross section
scrum anxiety

“Search Term Haiku” is a series wherein I examine this site’s log files and construct one or more haiku poems from search terms and phrases that led visitors to the site. Where possible, I attempt to keep the search phrases intact. However, as these are haiku poems, I do need to follow the rules.

“they don’t use a traditional UI”

by !undefined

Thought-provoking post by Tony Aubé: “No UI is the New UI”

There’s just one problem, “no UI” in this case just means “not the UI you’re accustomed to”, but more on that in a minute.

Aubé writes:

If you don’t know about these apps, what make them special is that they don’t use a traditional UI as a mean of interaction. Instead, the entire app revolves around a single messaging screen. These are called ‘Invisible’ and ‘Conversational’ apps…

Great! Cool! Interesting! But let’s get our terms straight here. Let’s recall that “UI” stands for “user interface” or (semi-formally) the mechanism through which a user interacts or interfaces with the system (be it software or hardware). If SMS is or some other “simple messaging” is the primary interaction modality, then that is the UI–which is very different from something having “no UI”. 1

In my Medium response to this post, I mentioned that “even your smoke detector” has a UI, even if that UI is “just” a little light, a button, and some annoying-ass low-battery chirps at 3 o’clock in the goddamn morning.

The really interesting questions getting raised here are around what a user interface is, and how much of it can you take away. Can you shield people from the complexity of buttons and search boxes and hamburger menus? Can your app do its thing through a “chat” modality? Or is that going to be confusing? Can you lose the visual interface all together, a la Siri?

These are great questions to be asking, and I’ll admit that I’m among the ones who are taking that for granted.

  1. And/but/so as an aside: Aubé also has this semi-throw-away line about the chat modality.

    Text is constant, it doesn’t carry all the ambiguous information that other forms of communication do, such as voice or gestures.

    This stuck me as unfortunately naïve since, after all, one of the main reasons that we (as human beings) get burned over and over again in our non-verbal communication is because there is plenty of ambiguousness. Our written words are usually a stand-in for our spoken words. And so if your speech tends to lean sarcastic, then I suspect that your written words will follow.[]