John | 11 August 2006

This past week, Eric and I have been designing and starting to implement the code framework for WeSay. I have rarely had a chance to do this kind of “green fields” architecture before, but I have done it enough to recognize some of the dangers, such as those described by Brook’s “second system effect”:

An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time.” Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a “big pile.”

— Frederick P. Brooks, Jr.
The Mythical Man-Month

Personas

As part of an effort to avoid this affect, one simple thing we have started doing is to use the UI notion of persona and apply it to the developers that might be helping us build WeSay, maintaining it someday, or writing pieces to plug into it. Some folks at Microsoft have blogged about this sort of thing. For example, Eric and I went through an exercise of thinking about the people we know who would be keen to write extensions for WeSay. We boiled down their essential common characteristics:

• Primary motivator is helping individuals they know through a technical related problem.
• Primary job is some kind of computer support of people doing language development. Enjoys programming occasionally for this job.
• Normally does “one-off” projects that help a single person/project.
• Has a background of working in languages that give you a big bang for your buck: VB, Perl, CC.
• Has a long history of directly manipulating text files.
• Has (possibly strong) opinions about file formats.
• Willing to try new things, but is used to being able to purchase a book about the topic.

We are calling him Sam, after the helper-hero in the Lord of the Rings.

Why are we interested in Sam? He represents a huge pool of talent, often untapped, and he will in many cases be the interface to the language development workers who would deploy WeSay. We want him to be able to say to a language-development worker “This thing called WeSay might really help you achieve your goals… I see you have this special need, but I could program up a little extension to solve that.”

We don’t expect Sam to be responsible for maintaining the WeSay code base, so it doesn’t affect the decisions we make there. What we would like him to be programming is extensions to WeSay that make it useful in some particular circumstance. Especially as we bring in paradigm changing “best practices” into our architecture, such as dependency injection and design patterns in general, we are trying to keep a close eye on Sam. Are we forcing him to understand these concepts? How big of a barrier will that be?

We haven’t worked out other programmer personas yet in this kind of detail. It would be nice to have one, for example, for a developer who is a full-time programmer and who could take over maintenance of WeSay from us. And perhaps another one for an open-source volunteer who would add new abilities to WeSay in their spare time. We’ll see how it goes with Sam.