August 10, 2009

Polyglot Programming's Impact on a Team

Polyglot programming refers to making applications that are comprised of multiple languages, each used to handle a specific aspect of the application. Polyglot programming is becoming increasingly popular and will only continue to do so over the next few years - meaning that general purpose languages like Java and C# won't be the sole language used on a project and will instead be augmented with other languages. I'm all for this approach but have always assumed that it meant the entire team would be proficient in all of the languages used on a project. However, reading the chapter on polyglot programming in Neal Ford's The Productive Programmer has me reconsidering this notion. Ford writes:

“All doctors at one time were general practitioners, but as their field advanced, specialization became inevitable. Software complexity is quickly driving us toward specialization, both because of the types of applications we must write and the underlying platforms.”

I had never considered polyglot programming leading to specialization within teams - and perhaps throughout the industry. So I could be working on a Rails site and have a contractor specializing in Haskell come in to work on some tricky backend code that needs parallelized. Interesting. Though when I think about it, this specialization is already kind of present in our team. There's a guy everyone goes to with their JavaScript and CSS problems, as well as another who's known as our SQL and SQL Server guru. We could continue this and have other developers on the team become experts in different languages.

There are definitely some benefits of a team practicing language specialization. When a team understands a variety of languages, it increases the breadth of their problem-solving abilities - and more importantly, it allows them to leverage the best language for each particular problem. Furthermore, specializing enables a developer to become extremely knowledgeable and efficient in a language, allowing him or her to really maximize a language’s capabilities, instead of having a team of developers who are merely proficient in the language and don't use it to its full extent.

However, there could be some potential drawbacks to this approach. Specialization could hamper knowledge dissemination amongst teammates and possibly create silos within the team. Similarly, it could lead to a negative outcome in the hit-by-bus scenario. That is, what would happen if a teammate was hit by a bus? Would the team be able to substitute the missing developer and proceed with a project, or does the missing teammate have knowledge or a skill set that no other team member has, thus crippling a project if he or she is not there? I know we have at least one person like this on our team, and he sometimes has been unfairly pressured to work because his absence would severely jeopardize the completion of a project. This is certainly not a good situation for the team to be in.

Yet these drawbacks can be mitigated and will certainly not impede polyglot programming's rise in popularity. I'm uncertain, though, whether it will lead to a team and an industry of language specialists - but regardless, I better learn some more languages (starting with some dynamic and functional ones).

So what do you think? Do you agree that polyglot programming will become pervasive in the industry, and if so, how will it impact the makeup of a team?

Posted by Tom Wessels at 11:09 PM
Labels:

4 comments:

  1. There are a few problems with the doctor analogy when it is applied to software development teams or firms. First, doctors willingly share information with other doctors at other hospitals on a regular basis. While I know that some of this goes on in software development, I think it would be unrealistic to expect that someone on the Bing team would be able to call up someone at Google and ask them how they implemented their Lisp interpreters to reduce overhead. Doctors just don't face the same kind of nondisclosure agreements or competition in terms of revenue and profit that software firms do, and therefor software firms are less likely than doctors to share information across companies. Taken into your hit-by-a-bus scenario, a software firm would not hand off a client to a competitor simply because their Lisp specialist was on vacation, but one hospital would send a patient to another hospital if their oncologist was out of town and it was an emergency.

    Second, it is true that doctor's have specialized, but so have their practices. For example, you don't find a lot of doctors' offices that specialize in eye surgery and obstetrics. Large hospitals do, for certain, but most doctors that are in private practice have an office of doctors with the same specialty (so that they can gain deep knowledge from one another) and then are on staff at hospitals where they can collaborate across specialties on a case-by-case basis. Those collaborations are often done simply to pass a patient off from one area of care to another and are usually not part of a long-term care solution.

    Third, even doctors have a myopic view of the world. If you are having trouble with your eye, for example, an eye surgeon will want to cut it open, a oncologist will want to test it for cancer, a vascular surgeon will want to run stress tests on the vessels, and a neurosurgeon will want to look for signs of brain damage. Each of them want to find a solution or an answer that fits within their particular specialty rather than looking for the best option from across the specialties, which would be the point of polyglot programming.

    Fourth, there is a single commonality across all doctors regardless of specialties: they all treat human beings. There are general rules that can be learned and assumed to be constant across body parts. There are definitely similarities across all development frameworks and programming languages, but at some point its could be more akin to a veterinarian and a surgeon working together.

    Finally, the real difference is that doctors go through years of training for general medicine and then years of training for their particular specialty before they are actually certified to practice in that specialty. As a medical student, they pay the brunt of that learning process (in tuition, low pay, long hours, etc), and the hospitals and practices get what amounts to cheap (though under-qualified) labor. In software development, the company would pay the brunt of that learning process (in training, inefficiencies, bad releases, etc.) before people are truly masters of their particular specialty. That hurts the bottom line with a potential return on investment of a decade, and anything that does that will be rejected.
    ReplyDelete
  2. When people discuss polyglot programming, I never hear anyone talk about whether or not these "specialist" programmers like the language they are developing in. I think part of what happens isn't just that a developer becomes specialised in a particular language or technology because the team demands a specialist for efficiency's sake. Part of what can happen is a developer tries out something new, finds that he likes it, wants to become better at it, and when scenarios arise where that technology is the right thing to use, he volunteers. After he does this a few times, it becomes habit.

    And maybe that's where we need a check every so often—making sure that habit hasn't created pockets of knowledge where it shouldn't. Does that developer still enjoy working with that technology? Would he like to try something else? Or, is another team member interested in learning that technology? Can we make sure that developer gets a chance to learn from his specialist teammate?

    Because while some people discuss the need for specialisation, others such as the agile and lean proponents push for teams of generalists. Their argument is that the specialist can be a bottleneck, which is also entirely true.

    There is no one perfect answer. Work with technology you enjoy. Explore it as much as you want. But also try to broaden your horizons so that you can find other technologies you enjoy.

    And no matter how generalised your team is, having a teammate get hit by a bus always involves a negative outcome. If it doesn't, you have a bigger problem.
    ReplyDelete
  3. Mike,

    I agree that the doctor analogy is weak; I often cringe when I hear software development likened to other industries. Yet I do believe polyglot programming will continue to increase in popularity, but I'm not certain whether it will lead to team or industry specialization. I see reasons why it could (and should), as well as reasons why it couldn't (and shouldn't). Are you simply arguing that the doctor analogy is poor, or are you also showing why specialization (and perhaps polyglot programming) won't become prevalent in the software industry?
    ReplyDelete
  4. programmergrrl,

    First off, I absolutely agree that having a teammate get hit by a bus is always a negative outcome. I don't mean to convey the opinion that developers are simply cogs in a machine that can be swapped out at any time, as I completely disagree with this sentiment.

    You list some great ways of mitigating the potential negative consequences of specialization. And yeah, I used to (and probably still do) think that having a team of generalists is better than specialists. Personally, I've always wanted to learn as many languages and technologies as I can, as it makes me more valuable, allows me to work in any area of the project or product, and spares me from potential burnout caused by strictly working within a single technology/language/area of the product.

    However, a coworker once made a strong argument for why he wants to specialize in a particular area, along with the technologies and languages involved with it. Being able to thus see both points of view is what prompted me to write this post.
    ReplyDelete

Subscribe to: Post Comments (Atom)