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.

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.

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.

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.

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.

Tap-tap-tap-tap-tap-tap; TAP; tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap; TAP; TAP; tap-tap-tap-tap-tap-tap; TAP.

When I’ve used vi and its descendants, it sounds like this:

Tap-tap-tap-tap-tap-tap; taptaptap; tap-tap-tap-tap-tap-tap; tapTAP TAP! tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap. tapTAPTAPtapTAP TAP!

And Emacs sounds like this:

Tap-tap-tap-tap-tap-tap; tapTAPtapTAP. tap-tap-tap-tap-tap-tap;tap-tap-tap-tap-tap-tap;tap-tap-tap-tap-tap-tap; tapTAP TAP; TAP TAPtapTAPtapTAPTAP. tapTAPtapTAP!

Lest you fear I’ve created some Ook-like language for describing shortcuts in any known editor, let me explain what’s going on here.

Cadence

Emacs is, at it’s core, a Lisp machine with a text editing language wrapped around it. Every interaction with Emacs invokes a function. Handily enough, the function that adds an “a” to the file you’re editing is bound to the a key on your keyboard. Oddly enough, the function that writes the file you’re editing out to disk is bound to the combination of hitting control and x at the same time, followed by control and s at the same time. Getting them out of order matters. Control-s followed by Control-x does something entirely different.

So when you use Emacs, you type a bit, and then you run some command. Maybe you save the file, or switch to editing another file, or go to peruse a directory. So you tap for a while and then you stop tapping, move your hands every so slightly to mash the control, or alt keys and then tap some other key, usually emphatically. The most commonly used key combinations end up being hit even more emphatically. Sit in a room full of developers using Emacs, listen closely; every once in a while, you’ll here everyone save almost simultaneously and go back to a furry of lower-case tapping.

Vi is slightly different from Emacs in that it is built up from two Unix commands: one for editing single lines of text, and another for moving between said lines of text. Thus, the cadence of a vi user is slightly different. Staccato taps followed by a bang as they switch from line editing to line navigation; more staccato taps, this time oddly spaced as they move between lines and place the cursor to begin their next fury of editing; another burst of staccato text entry; a quick and emphatic tap to take them out of editing mode and then a quick but punctuated trio of taps as they invoke the command that saves the file out, a sequence of finger movements so ingrained in the vi users brain that it appears as more of a gesture than a triplet of discrete key presses.

Here’s a project idea for pranksters: stand in a room full of people using vi and Emacs, listen for the really emphatic taps, and trip the room’s breaker right before they all finish their emphatic save commands. Cackle as chaos ensues.

The space between the taps

A roomful of vi-users, Emacs-users, and TextMate users is a homogeneous mess of clackity-clackity to the untrained ear. Most accomplished programmers are touch typists, so what you’re likely to hear is an undifferentiated stream of rapid-fire tapping. But if you’ve used these editors enough, and wasted enough time thinking about the aesthetics they represent, you can hear the differences in the punctuation as commands are invoked by arcane combinations and sequences of keystrokes.

In Vi and Emacs, there is a concise sequence of keys you can mash to do a regular expression search, move down three lines, go to the second sentence on that line, and replace the word under the cursor with “bad-ass text editing programmer, do not offend”. It is, in part, this power that attracts, fascinates, and empowers their users.

TextMate can do this, sure. But there is very little in the way of support from the editor to do it. You mostly have to put your eye on the piece of text you wish to edit and use some primitive motion keystrokes to get the cursor where you want it. Then you use those same keystrokes to highlight the text to replace, this time holding down a modifier key, then you type in the text you want. TextMate, compared to its programmers editor brethren, is a language of grunts and chuffs next to the sophisticated Latin or French of vi and Emacs.

Flow

TextMate is unsophisticated next to the extensibility and conceptual unity of Emacs, or the pure practicality of vim. So why do I keep coming back to it?

It keeps me in flow.

This is a very personal answer. I’m not saying you can’t achieve a flow-state with vi or Emacs. I’m saying that while I like the idea of those editors, understand the aesthetic, and enjoy watching skilled operators using them, I get lost in the punctuation when I use them. I either forget what punctuation I should use in some text editing scenario, or I have a nagging doubt that there is some better punctuation I could be using instead.

If vi is about navigating lines and editing those lines; Emacs is about invoking Lisp functions on files containing text, then TextMate is about primitive but direct manipulation of the text in a file. There’s very little conceptual overhead. You don’t need to know how the editor is enhanced in order to understand how to operate it. You don’t need to know when to put yourself in different modes of operation to make things happen. You just think of what you want the text to look like, you move the cursor around and you type on the keyboard.

It ain’t much, but I (often) call it home.

Software development on Unix has skewed towards focusing on tools, languages, and text editors for quite some time. IDEs and browsers on Unix are a messy, foreign thing (just like everything else in Unix). Thus, I’ve long favored the terminal-and-editor style of development.

I’ve decided that now is the time for me to try something different. I like text editors and directly manipulating text, but I can see why some people feel naked without an IDE. The ability to pop-up a level and make a more broad-stroked transformation to a program is appealing. Having code navigation and semantic awareness baked in has lots of potential.

I’ve probably said grumbly things about RubyMine in the past, but I think now is the time to give it a go. Worst thing that could happen is that I don’t like it and I go back to the infinite tinkering of Emacs or the 85% perfect experience of TextMate.

I’ll let you know how it goes.

I originally wrote that a few months ago, at the apex of my editor neurosis.

I did give RubyMine a try, and I like some parts of it. It’s code navigation is pretty nice, it does an admirable job of integrating with the unique ecosystem of tools that a Ruby developer uses to manage their environment, and it does an excellent job of grokking TDD with test/unit and RSpec. RubyMine is a step in the right direction. I suspect that if I had muscle memory for IntelliJ, it would be the way to go.

But, I have muscle memory for TextMate and Emacs, and I have an affinity for being close to my tools. RubyMine felt one step disconnected from both my muscle memory and my tools. That’s quite an accomplishment; most IDEs feel several steps removed the tools and seem to discourage developing finger-memory in favor of menu-memory. I’ll give RubyMine another try in a year, probably, see how it’s coming along. But in the mean time, it’s great to see that there is a vendor out there tackling the challenge that is tools for Ruby.

Ed. What follows isn’t novel, but it was a useful change in perspective for me, so I decided to share.

I’ve been thinking a bit about software processes lately. Despite great variation in telling you how to do so, most processes seem to focus on to do more stuff faster.

Lately, the notion of doing less has a lot of interest. Lean startups are the new-new thing and Getting Real is the old new thing; both preach getting more done and delivering value by doing less and analyzing the results more.

There are two kinds of “do less” a software developer can engage in. In the past I’ve been a little too focused on how I can take on fewer responsibilities from other parties. Literally doing less by scoping down features, putting off decisions, and focusing on things that seem like they really matter. I sometimes feel like I’ve become too eager to do less, making myself something of a cranky coder/slacker. But I digress

Recently, I’ve been trying to tackle doing less in my habits of creating software. How can I write less code to implement a feature, not in the minimalist sense, but in the “how do I just get it to kinda work sense”? How can I take less time between starting something and getting some form of it out in the wild? How can I make my code less coupled so there are fewer changes to make when I decide it needs to do something else? How can I make this less coupled to data storage so that putting it out requires less deployment effort? How can I make changes that are less likely to cause long-term regressions? How can I make it less effort to rollback bad changes?

When I look through the lens of accomplishing more by doing less, a lot of popular software methodology seems like dead weight. Rather than trying to find a process that addresses every team member’s own scars and affections, both perceived and imaginary, it seems most useful to imagine the smallest ruleset that won’t result in uncontrollable entropy and put it into action. If something starts to hurt, imagine the simplest new rule and put it into play.

The goal, as stated above, is to get to the point where you make really tiny, maybe imperceptible changes, and push them really frequently. Everything that stands in the way is the enemy.

My presentation for RailsConf 2010 focused on what ActiveModel and ActiveRelation provide and how one can use it to write cleaner code in domain models, how to make your models feel more like ActiveRecord objects, and how to use ActiveRelation to build your own persistence layers.

I hope you find the slides educational. Further, I’ve posted the examples on GitHub so you can play along at home. If you’re particularly interested in ActiveRelation, I hope you’ll find the examples useful as a starting point to using that library.

I first distilled these ideas into a talk I did at RubyConf 2009 on having more fun while coding. But I didn’t realize it at the time; I was just sharing some ideas about how to have fun. For me, one of the ways to have more fun is to make more time to have fun. But that’s just the beginning of making more awesome. I found I had to make more time, and develop a bunch of other habits.

For Big Design 2010, I honed the ideas, habits, and tricks I’ve found useful to me into a presentation on how to get off the couch, start making more things, and make some of those things awesome. I hope you’ll find it useful and perhaps start making lots of awesome stuff.