Software Archeology And Video Time Capsules

I was recently listening to Episode 338 of the Java Posse podcast, which is a recording of a session at the Roundup 2010. Near the 19:30 mark, a chap draws an analogy between software maintenance and archeology. Assuming the original team leads are no longer available, he asks (paraphrased):

• What was the culture of the team?
• What were the designs/philosophies of the original architect?
• How can we make those thoughts more explicit?

Software Archeology

I found the moment to be eloquent, and reminiscent of an episode of SE Radio, where Dave Thomas uses a similar metaphor: code maintenance ultimately requires us to understand a culture by analyzing artifacts. Call it software archeology.

Artifacts

We can all name the usual artifacts: an architecture document, UML diagrams, sequence diagrams, and so on. If we are lucky, perhaps there are tests.

Unfortunately, all too often, documentation is formal and poorly written. Reading it for culture is like trying to understand a society by reading its laws: useful, but abstract and without soul. Worse, the documentation may be out of date and only vaguely relevant.

A Potential Solution?

As consumers, we spend untold amounts of money on video equipment, which is both powerful and easy to use. We think nothing of uploading staggering amounts of video to the cloud, documenting our lives, and yet in the corporate environment, nothing. This strikes me as absurd.

In addition to striving for new wikis, language constructions, and formal diagrams, why don't we use video?

Consider this: what if the team lead gave a 1-hour architecture overview, once per release, and it was recorded and checked-in to source control? What if s/he took an afternoon to make a screencast of a random walk through the IDE? That is, what if we treated video time capsules as project artifacts?

For future software archeologists, they would be worth their disk space in gold. Imagine the simple nuances and gems that are so difficult to express otherwise (e.g. "yes, we are bending the usual use of aspects here, but there was a trade show deadline. We hope to address this technical debt").

Note that in my vision, the production quality would be low: these could be one-take, banzai attempts. Naturally, no one can possibly explain all of the corners of a code-base, but this isn't about corners: this is about culture.

Counterpoint

This strikes me as so obvious, that I must be missing something. Perhaps I am simply naive. Arguing against this idea, the main deterrents that I can see:

• Companies may not be prepared to buy and manage video equipment. In terms of acquisitions and stewardship, it just isn't part of their DNA.
• Managers may fear that video is somehow less secure than source-code.
• For highly regulated industries, what happens if a team-lead describes a design flaw or technical debt? Could this be a legal liability? (This could be a major deal-breaker, but certainly not for all companies?)
• There is no incentive for a team to prepare others for future maintenance. Even if video time capsules are effective, the status quo is good enough, and between leads, developers, and managers, no one will demand better.

What do you think? Does your team use video?

Koans

First, note that my former employer has a new look to its monthly newsletter, Software Engineering Tech Trends. I've always appreciated the articles (and wrote two), but now that I live in an area without many local user groups, I count on SETT when planning my study path.

January's article is a fantastic example. Your friend and mine, Mario Aquino, introduces us to koans, covering exercise packages in Ruby, Javascript, and Clojure (see comments for Groovy resources, Editor).

The Javascript example is especially easy to start and work with. A browser and a text-editor: it could scarcely be easier!

This is neat stuff. Read Mario's article for the full scoop on about martial arts training and Eastern philosophies. I'm definitely a newbie, but so far, I've noticed:

Testing as a contract

The koan style appears to embrace the view that testing is a useful prism for viewing an object. In normal software testing, the object is software, but here the focus is understanding. Despite a different focus, the tests as a concrete contract.

Not that we needed more evidence of being in a post documentation-centric era (post to follow?!), yet here it is.

Zork

Both the interactivity and the sense of Zen paradox reminds me of early text-based adventure games, such as Zork. It would take serious work and creativity, but I envision a learning app that combines the spirit of the koans with a sense of an adventure game. Potentially a great way to introduce kids into programming (or to their 2nd language etc).

Fun

Most of all, this stuff is outright fun. It's a potent combination of learning along with the electrochemical reward for passing tests. That's some mojo right there. What's not to love?

Pro Tip: Ask for a 999 Cut

Hello CtJ Nation!

A short post to wish readers a splendid holiday season and a happy New Year. Thanks for staying with me through 2010. It has been a hectic year, and I've been unusually quiet.

As a light-hearted thank you, I'm sharing some links from the Strange Passions sessions at the recent Strange Loop 2010 conference.

I once thought I was an interesting person, but after seeing these talks, one is humbled and entertained at the same time. Wonderful, wonderful stuff.

My favourites are Entering Without Breaking (it inspired the title of this post) by Galen Collins and The Science of Musical Counterpoint and Illusion by Daniel Spiewak. (If it matters, GC's talk is rated-R for occasional language.)

All of the videos are available here.

Be safe, and be joyous.

Language Panel

Here is a must-see video from Strange Loop 2010. It features a panel of icons and rock-stars, with another as guest host. The topic is the future of programming languages. It was a true treat to be there.

Some quick thoughts on the video:

Introductions part 1

Notice how the panelists didn't feel the need to list the languages they've worked with. Relative to their achievements, their intros are brief.

There is a calm confidence in brevity. I first noticed this when Dave Thomas introduced himself on the NFJS tour with: "I'm a programmer".

This separates the amateurs from the pros. Pros don't introduce themselves with the number of languages they know (a pet peeve of mine). It is assumed that everyone has worked with a dozen or more. It is true, no matter how impossible, that for every person in the room, there is someone else who has seen more languages.

Introductions part 2

Kudos to Alex Payne for paying respect. It struck me as sincere.

Introductions part 3

Guy Steele is one classy guy. Note his emphasis: he likes all languages. Each one has value and its own charming quirks. We get the sense that Guy is more interested in solving problems than the current fashion of the industry. He has an air that inspires me to take the high road, and stay above the language wars.

Language Wars

Alas, Guy's angelic aura only lasts for so long. The unvarnished truth is that I'm weak, and I can't resist language wars. Though the gang were rough on Perl, Crockford's irreverent non-comment on Parrot, near the 30:00 mark is priceless.

My Non Question

I nearly asked a question about escaping the surly bonds of ASCII in future programming languages. Unfortunately, I became distracted by my inner voice:

• Is this a dumb question?
• Am I asking this to impress the panel? To impress the audience?
• Didn't Guy Steele, in a keynote, have a Unicode symbol in Fortress? Why wasn't I paying closer attention?
• How could I travel 1800 miles for a conference and not have prepared a few questions?
  

And so on. In the end, I played it safe and sat on my hands. Though I may have avoided an embarrassing moment, I also passed up a chance at potential insight.

Lesson learned: brevity rocks; reticence sucks.

https download with Internet Explorer

I strive to link to posts that have saved my team's bacon, as a modest payback. It might help search engines, and will certainly help me remember the experience, in the event I encounter it again.

The problem: Internet Explorer won't download a document (e.g. an Excel report) via https.

The cause: probably cache-prevention in the headers, per Eric Law's post.

The bonus: Eric mentions Fiddler. That tool might be very useful in general, though I haven't tried it.

Keynote to 2-up PDF

This post is simply grateful linkage to a useful post by Alex Miller.

For a conference or business presentation, you may be asked for a 2-up B&W PDF. If you are like me, the first question is: "what is 2-up?" That question is answered here.

Easy. The next question is: how do I do that in Keynote? Alex's post gives the steps.

JavaScript and Expense Reports

This is a loosely-connected collection of thoughts stemming from the recent Strange Loop conference and a book purchase.

Background

For years now, I've known that thoughtful developers:

• separate the JavaScript language from the DOM and wretched browsers
• appreciate JavaScript as a lovely language inspired by (surprise!) Lisp

So, I thought I "got it". Aside from the usual web development, I've even written significant production code in ActionScript in 2003-4.

But I didn't truly learn the language.

It fell into the dreaded Multi-Month Void of Cognitive Decay (MMVCD).

Here's what I mean: I only faced JavaScript every 3-6 months or so. When it did show up, the situation was urgent, and I felt as though I had to re-learn the basics. Previous 'lessons learned' were quickly lost in the fog of war. I gradually associated the frustration of re-learning with the topic itself.

In this sense, poor JavaScript joined CSS and expense reporting software, falling into the dreaded MMVCD, a random window of cerebral entropy lasting between 3 and 18 months.

(However, even in its worst hour, JavaScript was certainly better than either expense reports or CSS, both of which occupy the darkest corners of MMVCD)

Motivation

Many friends have been interested in JavaScript (some in a career-altering way, no less). Many recommend Douglas Crockford's JavaScript: the Good Parts. It is mentioned frequently at conferences and user groups.

The tipping point was this review by Witek Radomski:

I used JavaScript as a garnish for web development... I was afraid of it. I knew I needed to confront the language and learn it properly.

Yow. This person saw into my soul. In fact, that review led to my recognition of the MMVCD.

JavaScript: the Good Parts

This isn't a book review, but: the book is a delight. Minus the appendices, the book is 100 pages in 10 chapters. That is an object lesson for authors and publishers alike! (I would love to know if Crockford faced pressure to add pages.)

What's more, the premise is a winner: a language can contain a beautiful, subset within a complex, (at times) unappealing landscape.

Random Thought #1: Chained Dictionaries

On SE-Radio, someone once joked that Lisp is nothing more than an abstract syntax tree. Funny stuff, and not entirely fair (I believe it is a comic reduction of an earnest point by Paul Graham, though I have no link to support that). Yet there is certainly a grain of truth in it.

My mental model of JavaScript: it has collections of properties. JavaScript does not call them dictionaries; I will. Dictionaries can be chained. A property may be a function. That's it: simple, elegant. Though this is neither fair nor accurate, that idea leaps to mind frequently.

Random Thought #2: Inheritance is an Interface

Scott Bale gave an excellent talk at Strange Loop 2010, based on Crockford's book. During the talk, it struck me: when we learn that a language offers inheritance, it is a fallacy (and audaciously Java-centric) to assume the existence of classes. Classes are merely one implementation of inheritance.

To wit, inheritance is an interface. It is a conceptual contract.

As most will already know, JavaScript offers prototype-based inheritance. This is a different ballgame, but must be understood, if we are to comprehend JavaScript. Crockford banishes the pseudo-class-based inheritance of JavaScript out of the Garden of Good Parts.

(As an aside, Crockford uses the terms 'prototypal' and 'classical'. I think this is a poor choice. To me, 'classical' has connotations of timelessness or an ideal. It took me a long time to realize Crockford doesn't mean to imply that.)

The Upshot

If, like me, you find JavaScript to be in the Multi-Month Void of Cognitive Decay, Crockford's book is a gem. I'll be working through it.

I realize there is now a book on HTML and CSS, but I don't think I have the stomach for it. Ping me when Expense Reports: the Good Parts is available.

Postscript

Be sure to check out the comments for interesting links on JavaScript material by Lambda Loungers.