Papers, references, books

Could have used this three years ago, but better late than never.

Vesper Sync Diary

Haven't read this. Wonder how much of what he learned is broadly applicable vs app-specific.

Scene: videoconference to discuss design of new dependencies feature
Me: I should warn you, I have a fourteen-year-old CS degree and I just went on Wikipedia.
My tech lead: (sighs deeply) Let me guess, topological sort.

Given what we know about software timeline estimation, "sprint" is a pretty bad rhetorical frame to use on the reg, right? Maybe it should be "a nice jog followed by dinner with your family". Then half the time it'll end up being a sprint anyway.

I wonder if there's ever been a software company that said "you know what, we're going to do everything slowly. 100% stop and smell the roses pace." But did a good job at what they did do.

"... if it takes you more than 5 seconds to think of an appropriate icon ..." then don't rely on an icon there. Nielsen/Norman on icon usability.

Think of it like this: jumping in a Mario game is very simple. You hit a button, Mario jumps. But once you know how to jump, you can use this ability to jump over gaps, jump on top of bricks, kill enemies, destroy bricks, hit coins out of coin bricks, get mushrooms, jump on top of flagpoles to get points, and much more. Learning one simple thing unlocks a very deep array of options. These are the kinds of features you want in your application.

- Lukas Mathis

This brings to mind a number of different analogues, but none of them fully capture what Lukas is saying: composable functions, rule-based systems - we can say "what is the simplest set of orthogonal abstractions that will enable all the desired outcomes" but that fails to capture the joyful feeling you get watching your character bounce across the screen, which even spreadsheets should in their own way aspire to.

• Do people know what they're talking about when they say agile development?
• Academic papers on Hadoop and MapReduce
• What happens when you get drunk?

This book looks interesting.

"But with a groupware product, nobody would ever work on it unless they were getting paid to, because it's just fundamentally not interesting to individuals."

But: I'd count a wiki as groupware, and 'have a place to plan my Burning Man camp with my friends' definitely meets his criteria for useful software (cough).

Mostly basic principles of survey design, so applicable beyond software. Plenty of useful nuts and bolts stuff.

Would be nice if people stopped considering the success of open source (both as a development model and in terms of corporate adoption) as this impenetrable mystery.

This whole "less is more" thing can go too far. All else being equal, more features = more customers. Yeah, even for the iPod. The iPod's design would have gotten it nowhere if it didn't have the key features.

Too. Many. People. (see also)

(the post that started all this should be required reading in every application design course, although I think his reductio gets a little absurdum ... wait a minute, does application design exist as a discipline at all? programming, database design, UI design, sure ... but application design understood as a very special case of product design?)

(what the apple process looked like)

The benefits of mixed determinism and non-determinism in parallel programming.

Looking for lightweight processes for going from "an app that does X", through mock-ups and use cases, all the way to a functional spec. Links below may or may not be on target.

• IBM: user-centered design
• Apple Human Interface Guidelines: The Design Process
• Joel on Software: Painless Functional Specifications (with useful example spec)
• And finally, putting to rest the idea that any of these will work the first time: c2 wiki: Iterative Development