Monday, January 31, 2011

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.


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.


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?

Monday, January 3, 2011


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.


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).


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?