Making the complicated seem simple

Don Norman, Simplicity Is Not the Answer:

We want devices that do a lot, but that do not confuse, do not lead to frustration. Ahah! This is not about simplicity: it is about frustration. The entire debate is being framed incorrectly. Features is not the same as capability. Simplicity is not the same as usability. Simplicity is not the answer.

Norman goes on to explain how you can take a confusing mass of features and turn it into something less frustrating:

  • Modularize into understandable clusters
  • Map clearly from actions to results
  • Model the ideas and actions cohesively

The article is about interaction design, but it fits just as well in designing programming languages and software.

Posted in Design | Leave a comment

Form: follow your influences

Now that I’ve sort of ranted about tinkering with software and how it is less important than writing, let’s talk about form.

I’ve found new energy in writing here of late. Part of that, I think, comes from thinking about a handful of weblogs that I really enjoy and figuring out how to emulate them on my own terms. What I find most intriguing and energizing to study is the framework within each author writes.

Shawn Blanc is a tasteful writer and curator. His site brings me interesting insight into design, aesthetic, and interface. I like his even-handed mix of original and linked content, his in-depth pieces, and his dedication to words over imagery. You can tell I’m thinking of Shawn when I write lengthy pieces examining an idea from all sides or when I post shorter links with a few sentences on how the linked article fits into a larger idea or aesthetic I find intriguing.

Tim Bray has his hands on many of the technologies and ideas I use on a regular basis. On his own weblog, he often goes off into the weeds of an idea, documenting an intellectual journey of trying to understand a topic that is new or interesting to him. I don’t always agree, and even find some of his stuff boring, but love it when he grabs hold of an idea and works on it. You can tell when I’m wearing my Tim hat (not literally) when I write a serial, a bunch of posts tied together by some idea, trying to figure out where the idea leads and how it fits into the bigger picture of an intellectual journey.

Jason Kottke is sort of the original gangster of curation. He is at his best and prolific when he is pulling together ideas, finding the unique and wonderful stuff. But more importantly, his erudition puts a lot of ideas and topics together I don’t normally come across. Sometimes I post things that aren’t really on topic for this weblog, but I do so because I think they represent the “cult of personality” of what I find interesting or exciting; this is me playing the Jason Kottke card.

Rafe Coburn is also a curator, but his topics-of-interest go a bit deeper, a little nerdier. Rafe’s at his strongest when he’s pulling together ideas about psychology, economics, science, and history. He uses these ideas to explain the political and technological world we live in. He does so in an opinionated way, but one I find easy to read and non-offensive, even when I disagree with him. I’ve yet to master his tone and the skill by which he brings ideas together, but if you see me posting on topics that are a little boring on their surface, its me trying to make sense of the world in the way that Rafe does.

Matt Webb is the island and the bridges between thinkers, dreamers, and makers. For years, I’ve followed his work, delighting in how he brings science, futurism, technology, and materials into wonderful and contemporary ideas. Even better, in his company’s recent work, he makes these futuristic ideas happen. Should you ever find me wandering into oddly disparate ideas, trying to pull them together into something wonderful, it’s likely I’m doing my own faint impersonation of Mr. Webb.

So that’s who I’m influenced the most by lately. The writers whose form, style, and excellence I strive to emulate, whose work I most enjoy. Yours are probably different. But the formula is the same: figure out whose work you aspire to the most, write a post about why you admire their work, and then get to work living up to the bar you’ve set.

Posted in Expanded ideas | Tagged | 1 Comment

Adam’s guide to switching weblogs

Over the past few years of writing on this weblog, I can’t tell you how many times I’ve convinced myself that now is the time to move my stuff to new software. Oh, the shiny and wondrous things that must be on that grass that is so much greener on the other side. This, despite having written at least once before on whether one should implement their own blogging app.

Consider this my yearly devotion to not rejiggering things.

WHEN SHOULD I REWRITE/SWITCH/REDESIGN MY WEBLOG, ADAM?

If your weblog software is so broken you can’t post, get some new software that you can post to and port all your old content to it, taking care to preserve links and such (so much as possible; don’t worry about boiling the ocean).

If you make your monies blogging, follow your needs; actually you should largely disregard anything I say.

If you’re a designer by trade, I’ll allow that it’s often good for your cred to pop a hot new design a couple times a year; just make sure that only one in ten of your posts are about your fresh new redesign.

ADAM, YOU HAVENT MENTIONED ME YET, I’M CONFUSED.

I’m getting to you!

  • If you’re a writer, just WRITE
  • If you’re a coder, just CODE

BUT BUT BUT!!!!!!!

No, really. The important thing about a weblog is that you put your ideas and experiences down in writing. You work through your thoughts. You put them out there for people to ignore, criticize, or praise.

You may have a lovely thing where you post links, images, funny videos, etc. Great, me too! But I’m not talking about that. I’m talking about banging two hundred words or more together into a cohesive, intriguing idea.

MAKE WORDS, NOT MARGINALLY USEFUL SOFTWARE SHUFFLING.

Posted in Expanded ideas | Tagged | 1 Comment

Michael Feathers on how code grows

Festering Code Bases and Budding Code Bases:

Some teams produce what I call a festering code base. In a festering code base, the team changes the code primarily by adding code to existing methods and adding methods to existing classes. The results are predictable. Classes and methods grow malignantly, eventually becoming thousands of lines long.
Better teams produce budding code bases. Developers create new classes and methods and delegate work outward. Periodically, they collapse structure back into a simpler form, but the dominant trend is to grow the code by creating new structure.

I’d never put much thought into how code bases grow in the past. Feathers has some interesting ideas here about the characteristics of good and not-so-good growth and how languages and tools might promote good growth.

Posted in Code, Curated | Tagged | Leave a comment

Incremental deployment at GitHub

Over the past year, I’ve read a lot about how teams are deploying their software. I’ve known for a while that Google has the ability to roll out new code to a small percentage of their servers and ramp up the breadth of deployment if they like how the software is behaving.

Lately, I’m starting to see more and more teams implement that sort of functionality. Rick Olson describes how GitHub implements it in How we deploy new features, and includes links to how Forrst and Flickr do it as well. At Velocity, Paul Hammond explained how to build an application-specific kind of version control into your app.

I’m a little surprised that few libraries have emerged for managing this. It would seem that, given all the excitement about continuous deployment, automated rollbacks, and incremental rollouts, someone would come up with something that they think is neat enough to share. I suspect that in fact, this is a really ugly, deeply application-specific sort of thing, no one likes to look at how they do it, and that’s why there is plenty of talk about how to do it, but no libraries making it a simple thing.

Posted in Code, Curated | Tagged | Leave a comment