What's Your Persona?

I recently read a blog article by Kas Thomas called "Programmer Personas". Apparently, some time ago when developing Visual Studio, Microsoft spent a good deal of time classifying programmers into different personas in an effort to better design the developer user experience ("What is an End User Software Engineer?"). The personas Microsoft identified were (I copied these descriptions from Kas's blog post):

• THE SYSTEMATIC DEVELOPER: Writes code defensively. Does everything he or she can to protect code from unstable and untrustworthy processes running in parallel with their code. Develops a deep understanding of a technology before using it. Prides himself or herself on building elegant solutions.

• THE PRAGMATIC DEVELOPER: Writes code methodically. Develops sufficient understanding of a technology to enable competent use of it. Prides himself or herself on building robust applications.

• THE OPPORTUNISTIC DEVELOPER: Writes code in an exploratory fashion. Develops a sufficient understanding of a technology to understand how it can solve a business problem. Prides himself/herself on solving business problems.

Generally speaking, these classifications are rather broad, but I think I can fit most programmers / developers into one of these classifications.

Do you do the same for your customers / clients when you design your software? Probably not. However, given the fact that more emphasis is being placed on user experience all the time AND the fact that identifying user roles / groups is a core requirement of BPM-related projects, you should.

For your next project, take time at the front end (plan it in) to classify your users and design / build your application to cater to these user personas. It will make your application better, and more importantly, your application will be better received by your users.

Leaf Blowers

Have you ever seen those guys who cut grass that use a leaf blower?

As I was taking my usual walk the other day, one of them was blowing leaves and grass clippings across the sidewalk into someone's flowerbed - out of sight, out of mind.

That kind of behavior really gets to me. And it's not just landscapers that exhibit this lack of judgment.

I am seeing this kind of behavior with software engineering and application development professionals - especially as the complexity of coding increases.

Here's what I mean.

Software code can be generally thought of as either internal or external with respect to other aspects of a system, specifically if your company is a software vendor. The external code is the code that the source is available and the internal code is the code that the source is private.

What I've noticed is that internal code, if you decompile it, oftentimes looks like the flowerbed where the leaves and grass clippings were blown. It seems that some software engineering professionals allow their code to get cluttered with bad or ill-designed code that has been swept under the mat of abstraction and encapsulation (to use object oriented terms), and left there - out of sight, out of mind.

I urge software professionals and vendors to clean house. Your code needs some spring cleaning. Dust out the cobwebs and sweep under the mats. And then, put in place some best practices (continuous integration with unit tests would be a good start) that will help keep the leaves out of your flowerbed.

Just promise me one thing... Don't be a leaf blower.