afongen

Scott Mark points to Burton Group’s new Identity Blog, and he’s right: it’s quite good (in the American, not the English sense of the phrase). Subscribed.

He goes on to praise their enterprise licensing. I agree. When my employer first took advantage of this licensing and gave us all accounts, I had two reactions. First, I was put off because the email from Burton announcing my account came out of the blue and I assumed it was spam. Bad form. Second, I wondered why the hell I would even want access in the first place. I had no idea who Burton Group were, and my impression of large analyst firms had been very negatively colored by experience with Forrester and Gartner (“writing” reports in PowerPoint? WTF?), neither of which I had direct access to but that seemed to have led to some sadly uninformed decisions.

I ignored the service completely until earlier this year, when I felt suddenly compelled to learn everything I could about digital identity and read everything I could get from Burton Group. (If you ever explore identity management, you need to read a lot, because none of it makes sense until you’ve read it all.)

Now I read almost everything they publish. Why? Eric Sink makes a distinction between developer and programmer that I find useful. A programmer specializes in writing code, but a developer gets involved in many ways in developing software. I am not just a code monkey. As much as I live writing code, not only would focusing on that to the exclusion of all else be bad for my career, it would be boring. Instead I find myself contributing in a number of ways to any project I touch. I need and want to understand the business behind what we’re doing, the big picture behind the technology I work with, the industry trends that are informing decisions being made at the top. Burton Group’s papers generally drill down into a reasonable level of detail, so I don’t feel like I’m just getting the highlights.

The benefit to my employer should be obvious.

So to whoever set up this access: thank you.

It’s also good to see Burton Group doing more blogging. The CEO has a blog on the site, which is interesting enough, but until the Identity Blog, that was it. You have to dig on your own to find their analysts’ blogs (e.g. Mike Gotta’s), which are hosted elsewhere. Too bad. Despite the strength of the white papers and the research behind them, I’m still probably influenced more on a day to day basis by analysts’ blogs.

This is where, without adequate transition, I point to RedMonk, whose work I follow a bit too closely for my own good.

I’ve spent my life immersed in language. By the time I graduated from high school, I’d studied at least a dozen: French, Spanish, Italian, Esperanto, Russian, Mandarin, Irish Gaelic, German, Latin… French is the only one I learned very well, but still I developed a profound appreciation for how study of one language can enrich my understanding of others, including and especially my native tongue, English. In college, as a French major with a linguistics emphasis, I of course studied even more languages. Frequently I found myself better able to express or understand certain ideas in languages other than English.

My father was a programmer and often expressed his conviction that there is a connection between languages used for programming and those for human communication, asserting that they occupy the same area of the brain. I have no idea whether that’s true, but it sounds reasonable and I’d believe it. He, too, had occasion to learn new languages for his work, although the only ones I ever knew about were C, C++, Ada, and possibly COBOL. I think it no accident that the first programming language in which I felt truly at home was Perl, which is strongly influenced by linguistics and ideas about human language and expressiveness (see, for example, Allison Randal’s “On Topic“).

It should come as no surprise that now, as a working programmer, I believe the study of multiple programming languages to be not only extremely valuable, but essential. And maybe it’s close-minded of me, but it surprises and disappoints me when other programmers do not feel the same. I work on a team of Java programmers, and with one exception I am the only one who is even remotely interested in things outside the Java world. This is crippling. That sounds like an exaggeration, but I believe it to be true. A monoculture is limiting and dangerous. It doesn’t matter whether you’re working with .NET, Java, Ruby, or whatever. Working under the assumption that a single tool can be an effective one-size-fits-all tool is a serious mistake. It limits your thinking, it limits your creativity, it limits your ability to solve problems.

Here’s some advice I recently gave someone who was looking to hire a .NET web developer:

I’m not suggesting that you hire someone who isn’t strong in .NET. If you don’t currently have strong .NET skills, then obviously that’s a very important consideration. Neither am I suggesting that you look only at developers with experience in .NET and something else. I’m suggesting that a candidate who has experience with .NET and another platform may — may — turn out to be a stronger candidate because s/he can critically assess what .NET has to offer rather than blindly follow the One True Microsoft Way.

I work with Java programmers. That’s what they are: Java programmers who happen to be working on web apps. Except for maybe something like Scheme covered in an intro computer science course, they don’t have experience with anything but Java. And it hurts us. Because when they look at a problem, all they see is Java. When I suggest a way of doing things that isn’t a canonical approach in the Java world, I get strange, uncomprehending looks. And we end up with overarchitected, overcomplicated application designs that solve problems we don’t have — or that fail to solve the ones we do have.

Example. An complicated call stack for a form submission that retrieves search results. POST form, push criteria to the call stack, redirect to a GET to the results display page, pull criteria off the stack. Okay, the call stack isn’t complicated, but the code behind it was. The programmer who designed this spent a long time working this out and unsuccessfully trying to address problems like dealing with multiple windows. Solution? Submit the form with GET in the first place. Dead obvious to a web developer, not so much to a Java programmer who’s not used to the web. But maybe that’s not fair since it’s a domain problem.

Example. A former coworker insisted that the text output of a certain COBOL program could never be parsed and made into something more meaningful. Why? Because he was exclusively a Java programmer, and Java’s a pain in the ass for text manipulation. Well, I work with languages like Perl and Ruby, steeped in a history of text manipulation. I munge text for breakfast. I looked at the problem and figured it would take about half an hour with a few regular expressions. Java didn’t even have regular expressions in the core API until four years ago, so this way of approaching a problem still doesn’t occur to most Java programmers.

Example. I find myself cleaning up a lot of clunky JavaScript code, written by people who treat it as “Java Lite” and who don’t understand JavaScript’s object model, which is quite different from Java’s. Different, not worse — and certainly not the One True Java Way.

I’m not writing this to rag on Java programmers, it’s just that they happen to be the source of my daily frustrations.

All this said, it’s quite possible to have an excellent web developer who knows only Java, or .NET, or ColdFusion, or PHP, or whatever. Regardless of whether they’ve worked in a diversity of languages or have been steeped in a monoculture, I think it’s worth asking about the strengths and weaknesses are of their chosen platform, because it’s a strong indication of how carefully and how creatively they’re thinking about the problems before them.

This is part of why I worry about what to suggest instead of Java EE, or rather what we can introduce to Java EE to be more productive. Part of my growth as a developer has been learning that not everyone has an easy time learning another language. I have always had an easy time learning languages, whatever the sort. I love to learn a new language, to stretch my mind and see what it has to teach me. This is far from universal. But I have to keep reminding myself of that, especially when I have trouble understanding why so few people are interested in extending the Java platform with non-Java languages.

More on that another day.