In recent columns, I’ve been talking about language and paradigm selection from the standpoint of the developer. I’ve pointed out that functional programming techniques are already more widespread than generally acknowledged and predicted that FP will grow in influence. I’ve also tried to argue that FP has some major drawbacks, such as a lack of great communicators and a willingness to promote silver-bullet thinking, which might keep functional languages from “crossing the chasm” and doom them to remain what they are now: a highly influential niche.
This developer-centric discussion might lead some readers to think that I’m recommending that development teams embrace Haskell, Scala or F#. And while it’s true that I think that many developers would enjoy and benefit from learning a more “pure” functional language, and that the benefits (and shortcomings) of a language often only become apparent when solving real-world problems, what’s good for an individual developer is not necessarily good for the organization. At the organizational level, I think it’s still quite rare for a functional language to be appropriate for core development.
While “write a project using F#, commit it to version control, ask forgiveness” may be an acceptable approach for a few scripts relating to DevOps or system administration, it’s most certainly not an appropriate way to approach choosing a programming language for an enterprise system.
Generally, selecting a programming language is one of the riskiest choices that a program manager makes, as it binds the team to a technology environment: vendors, libraries, conferences, educational resources, etc. Selecting a programming paradigm is even more dramatic.
Putting aside for this column the technical and conceptual pluses and minuses, I want to concentrate on the risk aspect. It’s been said that the job of software project management is the job of risk management. That goes a little too far, but it has far more than a grain of truth to it. The current vogue in technical project management, driven by Apple’s dazzling decade of innovation, elevates vision and execution above all else, and the Devil takes the hindmost. (Or, as Ricky Bobby so eloquently put it, “If you ain’t first, you’re last.”)
Most of the lists of risks I’ve seen in recent years have overemphasized low-risk, high-impact problems (e.g., “Our supply-chain did not supply the new sprocket at the end of the first quarter. We can’t scale to handle the success of our launch. A meteor strikes our data center.”). They rarely accurately present the real risks, which include such mundane things as troublesome subcontractors, requirements creep, insufficient input from end users, and new technology.
“Inexperience with the chosen technology” appears as a major risk in every quantitative analysis I’ve ever seen, and this is one of the few areas in software development where there’s actually a decent amount of research. Underestimating training or spin-up costs, overestimating productivity gains, unexpected internal resistance to change: All of these contribute to the risk when switching programming languages, and are doubly risky when switching paradigms.
Further, even beyond the scope of the initial product phases, risk management demands that project managers consider the maintenance and evolution of the code over time. Of course, if one chooses an obscure programming language or other technology, there’s the possibility that it will wither. (I am not expecting any Modula-3 compilers to be available for the Google Glasses API, for instance.) But core software needs to be written with technologies that are not just viable, but are mainstream or close to mainstream.
The problem is that new technologies attract developers who seek novelty. The developers who, today, are embracing the challenges of working with today’s emerging languages are, in five years, going to be enthusiastic about working with tomorrow’s emerging technologies. At this point, none of the functional languages have established a talent pipeline that is clearly growing. Haskell’s popularity in academic circles ensures a certain supply of young developers, but idealistic CS grads are often poor matches for the sausage-factory realities of maintenance work.
This is not to say that corporate teams should avoid emerging languages. I firmly believe that tools make a tremendous difference in productivity, and I believe that the programming language is the most important tool of the developer. Further, if project managers only concentrate on what can go wrong and on covering their rear ends, it’s unlikely that any product will reach its potential, and it’s unlikely that the team will have the esprit de corps of a team producing innovative and high-quality products.
But the appropriate place for new technologies is not in critical projects. Every critical project is orbited by a swarm of administrative tools, importers and exporters, data massagers, and the like. Major projects have prototypes and demos and proofs of concept. There are many, many opportunities for teams to use emerging languages without overcommitting the organization.
The desired upshot of this is a team eager to use the emerging language in core technology. Even with a team that is enthusiastic about a language (and developers strongly tend to favor technologies they’ve been learning), the development manager must make a cold-blooded decision about committing the company to a technology. That decision needs to be made with the good of the company—not the wishes of today’s developers—paramount. Unfortunately, very few languages manage to enter the mainstream and become appropriate foundations for enterprise development.
Larry O’Brien is a developer evangelist/advocate for Xamarin. Read his blog at www.knowing.net.
