kuniform

Saw Jason Fried and David Heinemeier Hansson of 37signals give their spiel on getting real at DePaul University’s CTI school’s High Tech Entrepreneurship Club, accompanied by Marcel Molina. Frank Gruber has a fairly detailed synopsis here. What follows are some of my reflections on the presentation and meeting the gents. I skip much of the content of their presentation, since svn itself or Mr. Gruber there do it much better justice to it than I could hope to provide.

Overall, the presentation was one signal vs. noise readers are fairly familiar with, and I’ve already had much of the same Kool-aid to drink. The audience, mostly undergrads, was fairly sycophantic, and the atmosphere was pretty casual. There were a few humorous exchanges, though.

In particular, there was a bit of debate about whether air traffic control systems could be designed by getting real or whether they needed CASE tools and functional specification documents and things like this. DHH’s opinion was that air traffic control systems are a bit mythical in scope and daunting and may not in actuality be as complex as they are rumored to be. I thought that was a bit of a cop-out. From my limited understanding of air travel from working in the industry, those systems are far more complex than anything I have worked on, and they are definitely more complex than basecamp, for example.

Question 1: So, is there a point where system complexity necessitates or dictates a certain style of documentation or definition?

Both gentlemen described functional specifications as textual representations of a system. This is a bit of a strawman. When I was learning to walk Frederick Brooks had already described many of the same problems with functional specs that Jason or David hammer on today. In the intervening 35 years, though, there has been considerable evolution in documentation and process since Brooks’ work, including entire disciplines such as user centered design, usability engineering, interaction design, etc. I don’t mean to denigrate 37signals by saying it’s a strawman argument, though. It’s a brilliant move.

JF/DHH says these things are bad, horrible, stupid and the audience goes, “Oh really? And you’re so smart? Tell us how it’s done, then.” Then they proceed to tell the audience their methodology. Perfect set up.

Question 2: Is their approach right?

Let’s answer 1 and 2 together. I believe there are some areas where documentation is necessary based upon system complexity. The few places where I have seen some form of docs come in hands are mostly a few high level process flows and or content inventories. Now, JF/DHH would tell you the process flows are abstractions and the inventories have to be maintained separate from the system, bad news. I would agree, but I think the value of such documents are two-fold, neither of which has much to do with describing the system for development (how’s that for splitting hairs?).

A few years ago, at another DePaul CTI seminar the guest was some guy I’d never heard of, who’d run an Agile/Scrum methodology-driven project with 1,500 workers to deliver much of the code for an American jet fighter cockpit. DHH, in referring to the air traffic control system, and in general, mentioned many times the need to restate the problem statement and break problems down. This is the sort of Gordian knot world-view, in which the problem is simple from the right angles, hmm?

And this is what AgileGuy did, they had roughly 6-12 person teams reporting up in a noded structure, where each node was its own little scrum team interacting with various other teams like little APIs calling each other. From stories like his, as well as my own experience, I don’t believe that the size of the system dictates the need for documentation, per se. I believe the organization dictates it.

Very often, especially at mega-co’s, process flows have value in and of themselves for training and providing common conceptual models at an appropriate level of detail. Especially when dealing with development partners, contractors, or new hires. Note: these are all things which 37signals is structured to avoid. DHH described documentation of process as “organization scarring” or something to that effect. Nice one!

Once, when working on a multi-language kiosk product, I had to contract with a translation service. Having a context matrix was invaluable in ensuring the kiosk had the right text in each language before the CD went gold and 1,000 copies of this thing were out in the world.

The software development methodologies used in many places today are designed to avoid and minimize risk. As such, they rarely produce successes and never produce innovations. Innovation is a risky business, and software development is risky as well, so people feel good when they hunker down and produce documents. They become convinced they are ‘adding value’ and that the boss won’t yell if the specs are in place.

I don’t think 37signals has the silver bullet, but they have something even more alluring: the promise of intellectual freedom. I have heard from co-workers past and present who’ve attended their 1 day sessions that “everything we do is wrong” because we often take great pains to do that type of work. They stay for the checks, but hate themselves in the morning, always believing the grass is greener over on the other side of the fence. Fried and Hansson stressed how less is less (not more) and that it allowed freedom from constraints. It is the freedom of the aesthetic, though, which is also the freedom to starve if you do not have the chutzpah to crank out some great work. So, to each their own decision—the gilded cage vs. the goal of professional fulfillment through following one’s own path.

Regardless of your choice (or mine), I thank both these gentlemen (and Marcel) for volunteering their time on a Friday night and being so patient and kind. They were each approachable, kind and considerate, with none of the attitude or instititutionally-based arrogance I’ve seen in so many mid-management folks with far fewer accomplishments at many companies where I’ve consulted or worked.

Anyway, thanks, good sirs, and see you at RailsConf. Next up, a post asking for feedback on my lowly presentation!