Personas and types

 

A little while ago Scott posted a post that got quite a few responses about the validity of personas and whether they are helpful in targeting customer segments or not. I'm going to stay out because many people who are smarter then me have already commented.

 

What I want to point out, though, is an interesting fact relating personas and static type languages. Traditionally, we viewed Mort as a developer that did not care about types and thus, VB6 was a language that was traditionally viewed as a Mort language. We viewed Einstein as a developer that built complex applications utilizing the benefits of static types and type safety (and thus, uses type-safe languages such as C# and C++).

 

What I've noticed, though, is that more and more, this distinction is no longer valid. People are creating complex applications and doing "Einstein" things using dynamic typed languages (JavaScript, Ruby, Python, etc). I've found I, too, am embracing dynamic languages more and more because of the flexibility that it provides when used appropriately. However I think that when used inappropriately, architectures built with dynamic languages are difficult to maintain and understand. But when done appropriately, the architecture can be simple and elegant.

 

I think the recent explosion of JavaScript, Ruby, Python, PHP, etc, has changed my traditional view of the world, and seeing the applications built on top of these languages has definitely changed the way I view the landscape of languages.

 

I think in short, I agree with what most people are saying - the personas are a limited (and thus limiting) way of categorizing programmers and therefore building our tools against the backdrop of personas may be limiting our software. The recent surge of JavaScript, Ruby and Ruby on Rails is clearly showing us the disadvantages of the traditional Mort/Elvis/Einstein model.

 

Yet I understand the need to create personas - they can be a very useful guide at times where the product is going in a hundred different directions.

 

Thus, the secret I think then is to determine how to balance the idealized personification model while remembering that not everyone will fit into the model nicely (and in fact, as Paul mentions, some people may be in all three categories), and we need to design our product to target the appropriate market segment yet be flexible enough to be easily adopted by people who don't fit nicely into the personification model. Flexibility and simplicity are tough and sometimes contradicting goals.