Dave W. Smith

Every so often a podcast comes along that’s worth several listenings. Today was number two for Nat Torkington’s “Design for the Future” talk from this year’s Webstock. Nat gives a history lesson that draws together the Crimean War, the Victorian internet (5 baud telegraph!), and Florence Nightengale (as an early proponent of reality-based medicine). He then looks at what those bits can teach us about current trends, looking in particular at the sad state of the news industry and at software development for cell phones. A thoughtful, informative, entertaining talk that I wish I’d been at in person. Fortunately, the audio quality is quite good.

I’ve been working my way randomly through the Webstock 08 recordings, and have been generally pleased with the quality of presentations. If you listen to technology podcasts, check these out. They’re a bit slow to download, but worth the wait.

In all of the discussion I’ve read about Google’s App Engine, I’ve rarely seen anyone call attention to the logo. That’s a shame. The App Engine logo is a brilliant piece of work.

I mean, look at that thing. Strap some stubby little wings on a big ol’ turbine engine, and get ready to go somewhere. What a great visual metaphor for the promise of programming against part of the Google infrastructure. And check out those understated colors. That is a logo that gets its point across without searing your eyeballs or resorting to smoke and mirrors.

Whoever designed the App Engine logo is due some major kudos.

A startup I worked for was recently acquired. Merger paperwork has been arriving in clumps. One document that invited my signature included the wording:

“You have reviewed and understand the escrow and indemnification provisions of Article VII of the Merger Agreement (attached hereto as Exhibit 1), …”

So, being in a responsible mood, I had a go at Exhibit 1, even though I’m way out of my depth, and am such a minor shareholder that were I to heave all of the paperwork into the trash, the merger would proceed without noticing my absence.

After slogging through nine narcolepsy-inducing pages of turgid legal prose, I found this little gem in the final paragraph:

“A decision, act, consent, or instruction of the Shareholder Representative, including an amendment, extension, or waiver of this Agreement pursuant to Section Error! Reference source not found, and Section Error! Reference source not found, hereof, shall constitute a decision …”

Now that’s I bit that I do understand.

I’ve seen teams “game” velocity, doing risky things (like letting unit testing slip and quality drop) to keep their velocity high. It didn’t occur to me that part of the problem might be terminology. Tim Ottinger’s “Velocity is Just Capacity” gave my thinking a serious nudge.

“Velocity” evokes speed and quickness. Speed and quickness are good. Speed and quickness win races and awards. A manager whose team has a high velocity is a winner. Recall Mike Cohn’s advice to alway append “billion” onto any velocity number that you give to a manager so that they can one-up their peers.

But consider the reframe: A team has a demonstrated “capacity” for taking on work. The prior iteration (or a weighted average of the past few iterations), establishes a Load line (AKA “Plimsoll line”) around the team. Load is a measure of capacity. It’s velocity as Agile uses the term, but without the baggage of evoking competition. Discussions about increasing capacity are subtley different from discussion about increasing speed. Tim lays it out nicely in his article. I think he’s on to something.

Is a terminology shift all we need to drive out bad velocity behavior? Sadly, no, but I think it would be step in a good direction.

“As the old Santayana quote goes, ‘those who do not learn from history are doomed to repeat it,’ but in Silicon Valley, those who rely on their command of history too much often find themselves getting crushed by a 23-year-old who skipped history class in favor of a CS degree.”

— Chad Dickerson

I’ve been using Django to build my latest scratch-an-itch project, and had been thinking about writing up a comparison of Django and Rails.

Ben Askins and Alan Green saved me the trouble.

Their presentation (which requires the latest Flash plugin) is a decent, balanced summary of the similarities and differences between the two frameworks. It’s 100 pages, but is paced for speed (and it’s a fine model for how to do compare/contrast presentations).

The only bit I’d add is that Django favors parallel development to a greater extent than Rails. With Django, you get to a clean separation between code and templates sooner, so that UI designers can be working on presentation while coding continues. And Django’s out-of-the-box admin interface supports lets people start doing data entry pretty much as soon as you’ve built your data models. Django doesn’t yet have migrations, though, so there’s more emphasis on getting your data model right up front.

Maybe one more bit: Rails has built-in support for AJAX and visual-effects, with several books that cover that support in depth. Django is JavaScript toolkit neutral, shiping with no built-in toolkit support (or no lock-in, if you want to think of it that way). For a sizeable project, I doubt this will be an issue, but for smaller projects this can give Rails an advantage.

If you’ve already chosen one of these frameworks, it may be worth your time to check out the other. There are good ideas in both.