Sponsored Link •
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.