Choosing Languages for Social Reasons

Bill Venners: You write in your book, Beyond Software
Architecture:

It is vitally important to understand how your team wishes to develop their
product. Surprisingly, I've worked with teams that completely reject agile
methods because they consider them the domain of "hacks" who don't know
how to specify and build reliable software systems. These teams demand
MRDs [Marketing Research Documents] and related documents; they have a
process and they follow it. As you can guess, I adjust my own preference for
agile processes to meet their needs. Forcing a given team to adopt an
approach that they don't believe in, either in their development process or in the
language they're using to create the system, is a certain recipe for failure.

My experience has been that the "right" choice—the right architecture, the right method, the right
language—has much to do with the situation. The individual personalities, the
history, the team culture, the particular business situation impacts the decision
as much as straight technical concerns.

Luke Hohmann: Most people tend to kid themselves that languages
are chosen for technical reasons. Languages are chosen for social reasons
and justified for technical reasons. No one genuinely picks a given language
for purely technical reasons. Why do you want to use a given language? Maybe
you're tired of using C, or you're tired of using Cobol. You want to use the next
language. It looks cool. You want to pad out your resume. You want to future
proof yourself.

Many of the reasons to choose a new language have nothing to do with
economic reality or technical need. One way to respond to that is to try to fight it
and make people choose the language for technical reasons. The other way to
respond is what I do when I work with a team. I say, "OK, it looks like you
have some choices to make about your architecture. Now, we could kid
ourselves and fool ourselves into thinking we're making these decisions
technically, but since we're behind closed doors, and since I am a consultant, so you
can tell me anything, why don't you tell me what you would like to learn, what
you think is cool, what you are interested in, and then we can see how far
away those are from the real business needs." Suppose someone says, "Oh, what I
really want to do is learn Smalltalk". The other people on the team might say,
"That's stupid. Smalltalk is a dead language. Who wants to learn Smalltalk?" So Smalltalk is not necessarily the best choice for that team, but at least you're talking about it
in an up-front way.

Bill Venners: How prevalent is resume-driven design, choosing a
technology based on what will pad out your resume?

Luke Hohmann: More prevalent than managers would expect, I'm sure.
I've had to kill some projects that were just
horrendously resume-driven design. My favorite example was a J2EE
monstrosity for doing something that a relatively simple set of Perl scripts could
have handled. I just walked in and said, "We can't fix it. We have to kill it." It was
millions of dollars down the drain. A complete waste. I'm faced with that
same situation with one of my clients right now. They're embarking on what
looks to be a really big J2EE project, and they're absolutely convinced that this
is the right thing for them to do. If someone would say, "The reason I want to do
J2EE is because I want to learn it," it would at least make some sense to me.
As near as I can tell, though, J2EE has absolutely no value for what they're doing. But
neither would .NET or any other über-technology. They just don't need that
kind of huge infrastructure.

Bill Venners: It's not only in the interest of the developers to be working
with resume-enhancing technologies. Language and technology choices affect
management's ability to keep the people they have and attract new people.

Luke Hohmann: I agree. That's another way languages are chosen for
social reasons, and justified for technical reasons. If you tell a candidate that
you wrote your system in Smalltalk, they might think, "If I take this job, it's a
dead-end career move for me." If you as a manager are justifying your
technology choices based on the idea that you're going to have to hire a
replacement or bring a future developer on, that's fine. You've not made the
choice technically. You've made it socially, and that's OK. That's a very fair way
to make the choice.