Google avoids it by sticking to a limited set of languages. I don't work at Google, so I can't claim to know what their architecture looks like in terms of blending languages within applications. But the act of limiting languages does not in itself preclude polyglot programming. Choosing to limit yourself to one language, or one language per application, would do so. Likewise, choosing C# and Java as your languages would probably nullify most of the benefits. But the point is, just because you allow or encourage polyglot programming does not mean you let everyone choose whatever language suits them and then throw it all together in a melting pot, praying that everything works well together. You can have a method to sort out the madness.

In any case, what's going on with polyglotism, and how do we implement it?

What's going on
Back in 2002, Bertrand Meyer explained why the pursuit of polyglot programming is worthwhile, even though no one was using it:

Let's start with the impolite question: Should one really care about multilanguage support? When this feature was announced at .NET's July 2000 debut, Microsoft's competitors sneered that it wasn't anything anyone needed. I've heard multilanguage development dismissed, or at least questioned, on the argument that most projects simply choose one language and stay with it. But that argument doesn't really address the issue. For one thing, it sounds too much like asserting, from personal observation, that people in Singapore don't like skiing. Lack of opportunity doesn't imply lack of desire or need. Before .NET, the effort required to interface modules from multiple languages was enough to make many people stick to just one; but, with an easy way to combine languages seamlessly and effortlessly, they may -- as early experience with .NET suggests -- start to appreciate their newfound freedom to mix and match languages.

Even then, the web was all about polygot programming: we see ActionScript, JavaScript, XML, SQL, and #{favorite_application_server_language} already.

Fast forward to the end of 2006, when Neal Ford was "beginning to see a time where even the core language (the one that gets translated to byte code) will cease its monoculture." And he sees it as more than the web's polyglot nature:

Applications of the future will take advantage of the polyglot nature of the language world. We have 2 primary platforms for "enterprise" development: .NET and Java. There are now lots of languages that target those platforms. We should embrace this idea. While it will make some chores more difficult (like debugging), it makes others trivially easy (or at least easier). It's all about choosing the right tool for the job and leveraging it correctly. Pervasive testing helps the debugging problem (adamant test-driven development folks spend much less time in the debugger). SQL, Ajax, and XML are just the beginning. Increasingly, as I've written before, we're going to start adding domain specific languages. The times of writing an application in a single general purpose language is over. Polyglot programming is a subject I'm going to speak about a lot next year.

Since Meyer's article, we have indeed seen an explosion of languages running on both "enterprise" platforms. Interest seems to have really grown recently. Because of that, it's getting easier to integrate languages. But as Neal Ford noted, we're still in the beginning (if you believe that paradigm is going to take hold).

How We Might Implement It
Like Neal Ford, Ola Bini seems to think polyglot programming is more than just the different technologies involved in a web application. He talks about how polyglotism might be implemented in layers within an application:

The first layer is what I called the stable layer. It's not a very large part of the application in terms of functionality. But it's the part that everything else builds on top off, and is as such a very important part of it. This layer is the layer where static type safety will really help. ...

The second layer is the dynamic layer. This is where maybe half the application code resides. The language types here are predominantly dynamic, strongly typed languages running on the JVM, like JRuby, Rhino and Jython. ...

The third layer is the domain layer. It should be implemented in DSL's, one or many depending on the needs of the system. In most cases it's probably enough to implement it as an internal DSL within the dynamic layer, and in those cases the second and third layer are not as easily distinguishable. But in some cases it's warranted to have an external DSL that can be interacted with. A typical example might be something like a rules engine (like Drools).

Let's talk briefly about a web application, as I envision it using Ola's layers as a guide:

In the stable layer, you might be talking about a banking application where transactions are performed in Java. You might have some tool set that performs important calculations, and which other applications depend on. It might be the parts of the application that really need to perform well.

In the dynamic layer, you might have code that integrates the static and domain layers. You might have code which glues together other stuff, or things which don't really turn into bottlenecks for the application, which aren't necessarily part of the application domain, but which don't require the ceremony of the stable layer. You're choosing to use a dynamic scripting language to increase productivity. You might define the DSL abstractions here, and use them in the DSL/domain layer.

In the domain layer is where you'll see the meat of your application code- it's where all your business object abstractions will reside, and they will in turn depend on the other two layers. It should consist entirely of code that uses business language.

Ola may have meant something else entirely, or just slightly different, but that's the way I've come to see it. The concept is still new, so there's nothing saying that vision of a "best practice" design will win out over ad hoc solutions that throw modules written in different languages together to form an application.

As far as low-level implementation specifics go, Ola Bini shared how he integrated Erlang and JRuby. Sean Corfield showed PHP and Ruby running within ColdFusion. Charlie Nutter has in-line Java for JRuby and of course there's in-line C/C++ for Ruby from Ryan Davis. Of course, most languages running on the JVM and/or .NET are fairly trivial to integrate with the libraries available to those platforms.

How I'm Using Polyglot Programming
How am I using polyglot programming in my day-to-day programming? Aside from the JavaScript/AppLanguage/SQL web paradigm, there are a couple of ways I'm doing it.

In one of my jobs, we do a lot of work with Sharepoint. In fact, the bulk of the applications are built in Sharepoint: to manage documents, content, data and get all the integration with other Office products. However, Sharepoint is a beast. Often, doing something that would be trivial on another platform is an arduous task in Sharepoint. So we have to drop out of it.

In some cases, when we've needed the feature to reside within Sharepoint itself, we've opted to use C# within ASP.NET to create Sharepoint Web Parts. For the next one of these I come up against, I intend to look at using IronRuby and deriving from the appropriate parent classes.

In other cases, we're building stand-alone "sub-applications" that integrate with Sharepoint and Active Directory. For these, we have some utility classes written in C#, while the "sub-application" is built in Ruby on Rails. Soon, we'll be looking at running them on IronRuby, and taking further advantage of the .NET platform.

In my job with the bioinformatics lab at the University of Houston, things are a bit different. I'm building command line applications. After a machine takes photos of your DNA sample, there is an genome analysis pipeline from Illumina that analyzes the images, produces nucleotide sequences, and tries to align them to a reference sequence. That utilizes Perl, Python, and C/C++, though I don't know to what extent a in which "layers" each language does its job.

On my end, I'm using C++ to do the heavy lifting in analysis in proprietary libraries we've been producing to do our own analysis and post-analysis. When you're dealing with genome-size data sets, from 5 mega- to 3 giga-bases, even constant reductions in run-time can mean the difference of days of computation in algorithms with above-linear time complexity. But I'm also building scripts in Ruby that help piece it all together, and doing some analysis with it for linear-time algorithms. It's very ad hoc, in this instance.

Finally, my game development group plans to use C/C++ to forge our engine, while using a scripting language(s) to fill out the game details. As I understand it, much of the game industry already employs polyglot programming in this manner.

So that's how I'm doing it at the moment.

In 2008, the polyglot programming paradigm is still (at least in my opinion), a relatively novel concept. There aren't a lot of resources to show us how to do it the right way. As time moves forward and people publish their experiences, that should be expected to change.

On that note, do you have any stories about how you've done it, or any ideas on how you would if you were going to do it? Please feel free to share them - you'd be doing us all a favor.

The theme in this part of Chad Fowler's MJWTI is reiterated here: don't rest on your laurels. You have to be proactive about keeping your skills up-to-date. Paying attention to the market, and acting on the knowledge that's available regarding the "in" technologies will help you do that.

Chad tells a hypothetical story about the demise of Java:

What if, for example, Sun Microsystems started showing signs of going under? Java isn't an open standard. It is dictated and developed by Sun. At any point, a dying Sun might attempt to suddenly make its language and virtual machine into a last-minute profit center. They might introduce incompatible changes or suddenly change the license restrictions of Java, causing an industry panic followed by a mass exodus.

With your head in your monitor coding, you might not even hear about something like this until it was too late.

What if you're a Flash guru and Microsoft's Silverlight comes pre-installed on 98% of the computers in the world as Adobe's Flash loses the support of management? Will Flash maintain it's market share? What if Adobe drops support for ColdFusion? Will the open source world carry the torch? What if Microsoft decided .NET isn't going to cut it for the next generation of programming paradigms, and scraps it? Will your skills in .NET be valuable for as long as your career keeps you working? What if management decides they want to standardize on a cross-virtual-machine dynamic functional language called Fan, and they want to keep the familiar curly-brace-and-semi-colon syntax? Will you still be using Ruby, Python, or Perl at your day job?

Are you willing to take those chances?

The most likely scenario is that these technologies will continue to exist, as they slowly fade away into the Next Big Things. As Chad notes,

Even more likely is that, comfortable in your current job with your current set of skills, you might remain blissfully ignorant of the Next Big Thing as it rolls in. Ten years ago, you would have been surprised to find out just how big object-oriented languages with garbage collection would become. But, there were definitely signs if you were watching.

Ten years ago we couldn't have done the work with DNA and large genomes that we can do today. More interesting problems (in bioinformatics and elsewhere) are able to be solved by more people just because of increases in memory, processor speed, disk space, and number of processors. What are you doing to learn about concurrency? What are you doing to learn about optimizations you can make? When constant-factor reductions in processing time save days to weeks of computations, it's not premature to make them.

Are you watching?

Suppose I decide I want to use ActiveRecord, but I don't have it installed on my system. Wouldn't it be nice to just type


and have IntelliJ IDEA (or Notepad++ or SciTE or Emacs or ...) just download it for me?

I need an MP3 library. Instead of seeing that there's no file to load, wouldn't it be great if the editor tried to find it?



All that needs to happen is that we have an index that checks for includes and references. If it doesn't find it in the standard library or any installed libraries, it goes to the index to find possible matches. If there's only one, it downloads it and continues. If more than one exists, it might ask you which one you want to download and include.

This isn't limited to Ruby. In fact, I'd love it more in Java and .NET. I can't count the number of times on those platforms where I've looked up how to do something, only to be denied by the fact they didn't mention the appropriate package or namespace to use.

Automatic Parallel Programming
Around the same time, I also thought it would be nice to have compilers and interpreters decide when concurrency would be appropriate:



This can get really tricky. In fact, we don't really want it to be automagical detection. There are some cases where it could happen, as far as I can tell. However, it's not worth the apprehension we'd feel if we didn't know when the compiler or interpreter was going to do so.

But there are plenty of cases where it is possible. I've been in several of them lately. Even forgetting about those -- Instead of typing the boilerplate to make it happen, I really want something almost automagic:



Not all operations would require a merge operation. But overall, wouldn't it be excellent?



The first is certainly possible. The second may require some research and work.

What do you think? Pipedream, or possible? So who's in?

Keeping a daily to weekly plan has helped me become more productive. I even tried to create a longer-term map of where I'd like to be by years end, along with various things I'd like to accomplish (which has only been semi-successful, if true be told). But one thing I've never done is create a map the way Chad's talking about here (pgs 151-152):

Your personal product road map is what you use to tell whether you've moved. When you're going to the same office day in and day out, working on a lot of the same things, the scenery around you doesn't change. You need to throw out some markers that you can see in the distance, so you'll know that you've actually moved when you get to them. Your product "features" are these markers.

Unless you really lay it out and make a plan, you won't be able to see beyond the next blip on the horizon. In Chapters 2 and 3, you discovered how to be intentional about your choice of career path and how to invest in our professional selves. Though I focused on what seemed like a onetime choice of what to invest in, each choice should be part of a greater whole. Thinking of each new set of knowledge or capability as equivalent to a single feature in an application puts it in context really well. An application with one feature isn't much of an application.

What's more, an application with a bunch of features that aren't cohesive is going to confuse its users... A personal product road map can not only help you stay on track, constantly evolving, but it can also show you the bigger picture of what you have to offer...

While it's definitely OK to learn diverse skills -- it expands your thinking -- it's also a good idea to think about the story your skill set tells. (Bold emphasis applied by me.)

For a couple of vacations I've taken in the past, I spun a pen on a map and drove to where it pointed the same night (up to 15 hours away). So far, my career map looks the same: as if a monkey tossed darts at a bunch of options and I decided to follow whatever the darts landed on.



I'm mostly a web developer - in the sense that I derive most of my income, write most of my code, and spend most of my time writing code that will in some way show up on the web or affect something that will show up on the web.

But I am also interested in, and spend significant time programming and studying artificial intelligence and machine learning, bioinformatics, and game development. I'm also interested in business for the sake of business (though I only occasionally write about it here). I enjoy writing desktop software as well (though I rarely have done so).

AI and game development dovetail nicely with each other. There are a lot of similarities between and overlap in algorithms for bioinformatics and AI. But short of creating a bioinformatics game on the web, it's hard to imagine where all these skills and interests intersect.

Perhaps it would be better for me to try and create a coherent picture out of the skills I choose to learn. But I rather enjoy having my hands and mind roam freely.

How's your skill set? Is it too focused, where you might need some breadth, or do you have a bit of a programmer dissociative identity, where some cohesion could take you a long way?

Why?

For one, if I'm right, it's something which no one wants to hear. Further, if what I said is correct, and it's a novel concept, most people will not yet be of that opinion. Backlash would occur naturally. On top of that, there's always the possibility that what I said is completely asinine.

Despite my expectations of imminent flaming, however, the people who responded raised some excellent points, which I'd like to address here, taking the opportunity they presented to clarify my initial thoughts.

First, it would be helpful to answer the question, "what do I mean when I say 'mostly fairly trivial?'"

Mostly: Most web applications.
Fairly: For each web application included in "mostly," it is trivial to a reasonable degree.

Put together, I would say "most parts of of most web applications are trivial."

I must have spent too much effort putting the focus on application generation, because by far, the biggest objections were there:

Barry Whitley noted,

The be-all end-all self building framework/generator has been the holy grail of software development since its inception, and it isn't really much closer to achieving that now than it was 20 years ago.

Along those same lines, Mike Rankin brought up CASE tools:

Anybody remember CASE (Computer Aided Software Engineering)? It was sold as the end of software development. To build an application, a layperson would just drag and drop computer generated components onto a "whiteboard" and connect them up by drawing lines. CASE was THE buzzword in the late eighties. 20 years later, it's nowhere to be found.

Software development will become a complete commodity the moment business decides to stop using their systems as a way to gain a competitive advantage.

To be clear, although I believe some applications can be entirely generated, I don't pretend that anywhere near most of them can. However, I do think that most parts of most web applications fall into that category.

Getting back to programming-by-wizard, at one point (very early) in (what you might call) my career, I programmed in G. This consisted mostly of connecting icons in what amounted to creating ridiculously complex flowcharts.



I think that's close to what many people envision as the "programmer killer" when they hear someone saying there will be one. But having used that style for a couple of months, I can issue my assurances that won't be it. In fact, as Mike said, since competitive advantage dictates businesses will continue innovating processes that will need to be codified in software, it's guaranteed there will always be software to write.

It's not a question of whether there will be software to write - it's a question of how much of it is there to go around for how many programmers, what skill-level those programmers need to be at, and what those applications will look like and run on.

Whereas a decade ago a team of programmers might have built an application over several months, we're at a point now where a single programmer can build applications of similar scope in days to weeks. We've even got time to add all the bells and whistles nowadays.

Within an application, we need fewer programmers than we did in the past. To stay employed, you need to learn how to use the tools that abstract the accidental complexity away, in addition to learning new types of things to do.

Barry puts it well:

As for the skills required, I'd actually argue that the workplace is demanding people with MORE skills than ever before. There is a lot of crap work for sure, and that market is dying out. For companies that want to be serious players, though, the demands are higher than they've ever been.

Indeed. That's what I'm talking about. The repetitive tedious stuff is going to be generated and outsourced. But there are shitloads of people still doing the tedious stuff. And there are shitloads of capable programmers who can glue the rest of it together.

We don't even need to get into the discussion of what will supplant the web and the number of jobs that will need to move around. The marketplace won't support us all at our high salaries. To be around in the future, you're going to need to do a better job of coping with change than the mainframe and green-screen programmers who won't find a job now. You're going to need to be capable of picking up new technologies, and the knowing the principles behind them will help you do it. Knowing how to build and design complex systems to solve complex problems is where you'll need to be. This is in contrast to being given specs and translating them into the newest fad-language. That's what professor Dewar was getting at, and that's what I'm getting at.

I don't expect most of the readers here will need to worry. Not because of anything I've done, necessarily, but because it seems like most of you embrace change.

I'm just sayin', that's all.

Any other thoughts? I'd love to hear them.

That's the discussion in this week's chapter from Chad Fowler's MJWTI.

The point revolves around the fact that hitting the goal is short-lived, while the process of getting there takes up the bulk of the time. Therefore, wouldn't it be better to view the process as the goal itself, and make that the enjoyable part?

My view diverges from Chad's here. Whereas he implies that this observation is a better way to live generally, I tend to think it applies to particular people doing particular things. For instance, I might agree that, in general, the US is "a nation of people who are always focused on the outcome of a process," I wouldn't agree that it's "one of America's biggest problems" (Quoting Chad Fowler, pg. 156). Still, I might be more inclined to think that people's choice of goals doesn't line up with my own.

Regardless of the small divergence of our beliefs about the theory in general, I do agree that it works for software development. I'm not talking about doing software development as a means to achieve fame, fortune, girls, and cars (or just as a means to do something else with your life). For the production of software as a means to reach goals (including some where the path is the goal), I agree with Zed Shaw:

I've been saying for years that you can live a life involving code and hacking as a cultural phenomenon, but you can't live a life that only has code. You can work and make money doing web programming, but you can't make a life out if it. I try fill my mind and experiences with other shit, and then use code as one of many ways to express myself.

Those kinds of goals are rewarding long after you've achieved them. Memories last until you forget them, and you can drive that Ferrari convertible up and down the Pacific Coast Highway until it falls apart.





But if you're talking about finishing a project as the goal, then you're likely to put yourself in a lot of pain during the journey.

Back to the software development example, it's easy to get wrapped up in the delivery of the code you are creating. Your customer needs a web application up, and you focus on finishing that application. But, a living application is never "done." One release leads to the next. Too much focus on the end product distracts us from the real deliverable: the sustainable development of a new entity.

Focusing on the ending makes you forget to make the process good. And, bad processes create bad products. The product might meet its minimum requirements, but its insides will be ugly. You've optimized for the short-term end goal -- not for the inevitable, ongoing, future of the product's development. Not only do bad processes make bad products, but bad products make bad processes. Once you have one of these products that is messy inside, your processes adapt around it. Your product's broken windows lead to broken windows in your process. It's a vicious cycle.

Sound familiar?

It does to me. A focus on a ridiculously short promised delivery date leads to no tests leads to coupled code modules and "quick and dirty" hacks in the code. That leads to an inability to test and more hacks in maintenance. And the cycle continues.

Wouldn't it be better to treat the process of making applications as the goal to be enjoyed, rather than masochistically torturing yourself?



What's your experience like? Are you more likely to treat the end as the goal or the path? Which works better for you?

That property is precisely what allowed frameworks like Rails and Django to come into existence and get popular. Soon enough, the money will dry up for implementation because it's too easy to generate solutions for most problems you'll encounter - either using a framework, or a content management system like Sharepoint or Joomla, or even by hiring someone to generate it for you. Yesterday I recommended a potential client just go the CMS route.

Nowadays, most of the skill involved in writing web applications amounts to gluing the disparate pieces together. How long until someone figures out how to commoditize that? Instead of knowing only how to implement solutions to problems, you need to be skilled at problem solving itself.

Right now, you might be in a position where you can kick back and count your money while you smoke a cigar.



But if you're in the business of building web applications and you're not innovating new kinds of them, you're doomed. You can chase vertical after vertical and keep building the same apps for quite a while, but if you don't get into generating them, you're on the way out as people come in who can do it cheaper than you and with higher quality.

Generation is to web apps as prefabricated steel buildings are to construction. Except almost no one cares if their web application was generated or not - they just want the lower price.

I suspect that even if you are generating applications, at some point in the future, the number applications needing to be generated will not have grown as quickly as the number of people who can generate them.

People are building complex data warehouses and doing analysis and reporting on them with GUIs and Wizards right now. You still need the knowledge pertaining to data warehouses, but that knowledge is becoming easier to obtain for more people with less effort than ever before. That trend, which fits in with the general trend of information democratization, is unlikely to reverse itself.

If you don't plan for change now, you'll end up shocked.



And then how long until you're pulling out the cloth-eared elephant?



What Dewar said is true: Web applications are mostly fairly trivial. To survive, you need to learn the fundamentals so you are applicable in various kinds of programming and for different platforms. If you really want to be safe, you need to be innovating, not building copy-cat applications with a twist (and especially not from scratch?!?!).

Giles Bowkett put it well when he described the effects of incompetent programmers' entry into a particular market:

Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down. (Bold emphasis mine)

The problem, in my view, is that the influx of incompetent programmers is inevitable.

So building well-known applications with twists becomes much like the would-be artist who looks at Pablo Picasso's work and says, "I could do that."

The obvious exception is that applications are not (usually) like art. Well-made knockoffs of the original aren't likely to be differentiable by customers from the cheap knockoffs, so the masses of incompetents and maybe the original end up defining the market in the long term.

After you've seen it, you could do this:



To which we all respond, "But you didn't, did you?"

As always, I welcome your thoughts in the comments below.

Not that Tiffany, this one:

Do you remember a pop star named Tiffany (no last name) from the 1980s? She was in the top of the top forty, and a constant sound on the radio back then. She enjoyed immense success, becoming for a short time a household name.
...
Apparently, if she tried, she didn't move fast enough to hold the affection -- or even the attention -- of her fans. When the tastes of the nation turned from bubble gum to grunge, Tiffany suddenly became obsolete.

(However, she's been making headway in changing that, as Chad notes in the book.)

The point remains: you need to stay sharp. You cannot sit back and become complacent. Doing so in this industry can cause you to become extinct. And you'll probably be less famous than Tiffany or the Dodo. However, Didus ineptus may end up describing you well.

One thing you can do to stay sharp is recognize that, relative to information growth, your knowledge and skill levels are deteriorating rapidly. The consequences of what Gordon Moore observed in 1965 is that new possibilities for computation arise at an astounding rate.



That graph looks linear, so what's the big deal? Look at the left - it's logarithmic scale. That graph really looks like this:



That slope is so high it's almost negative.

You can't keep up with everything - but you can't afford to be late to the party when it comes to new trends in development either. If you were a desktop application programmer in 1992 and didn't look up until 2002, you'd probably say a few WTFs, and then start drowing in all the information you'd need to get started programming web applications. There's a lot to learn in new paradigms.

So you need to anticipate changes. You might not be able to jump the gun on the next big thing, but at worst you'll have augmented your arsenal, and you can stay close to other trends as well. Reading blogs and staying current in news and even journals can help you find new, up and coming developments. Thinking about how things will change and backing your hypotheses up with evidence from the literature can be a worthwhile activity in that regard.

Looking ahead and being explicit about your skill development can mean the difference between being blind or being visionary.

Know that you'll be obsolete. Don't accept obsolescence.

How do you deal with the pressure to stay current? What new things are you learning?

Mmmmmmm...

---

Appetizer entertainment from The Osmond's aside, we can get to the salad plate of our four course meal: Jeff Atwood wrote a blog post about Dealing With Bad Apples where he quotes some of Steve McConnell's work:

If you tolerate even one developer whom the other developers think is a problem, you'll hurt the morale of the good developers. You are implying that not only do you expect your team members to give their all; you expect them to do it when their co-workers are working against them.

He goes on to quote McConnell's reporting of the data (something valuable McConnell always offers):

In a review of 32 management teams, Larson and LaFasto found that the most consistent and intense complaint from team members was that their team leaders were unwilling to confront and resolve problems associated with poor performance by individual team members. (Larson and LaFasto 1989).

All of that is to say: software developers with bad attitudes should not be tolerated for long, lest they destroy the team from the inside.

He continues, citing ways in which to identify miscreants on your team, finally concluding that

You should never be afraid to remove -- or even fire -- people who do not have the best interests of the team at heart. You can develop skill, but you can't develop a positive attitude. The longer these disruptive personalities stick around on a project, the worse their effects get. They'll slowly spread poison throughout your project, in the form of code, relationships, and contacts.

There's nothing too striking here. In fact, I didn't think twice about it until I read Brian Cunningham's response:

I agree with this wholeheartedly. But you also have to ask yourself whether there's something you could have done to prevent things from getting to this point.
...
Whenever a bad apple is discovered on your team, you should always consider the possibility that it could have been prevented. In many cases there's nothing you can do -- it's simply a conflict of personalities. But if you find situations where the bad apple could have been prevented, that means there's something in the management of the team that needs to be addressed. (Strong emphasis mine)

And then Jeff's words stuck out, reminding me of me:

You can develop skill, but you can't develop a positive attitude.

In my case, it was me who decided to develop the positive attitude. But that doesn't mean it couldn't have been developed by a skilled manager who noticed the problem.

Retrospective action is useful in avoiding the problems of today in the future, but often misunderstandings, miscommunication, and a lack of clear goals or motivation can be the cause of friction or a bad-apple attitude. So I take it a step further to the main course of our meal: Not only should you reflect on how the problem could have been averted upon discovery of the subversive, you should actively scan for potential problems and address them before they germinate.

It would not result in firings or team destructions, but instead focus on resolving the conflicts before they fully emerge. (Of course, if the problem is allowed to grow and fester, firings are encouraged.)

I'm not sure how to do that.

I don't personally have the answers regarding strategies for identifying problems and understanding what people really mean in conflict resolution, but I'm confident they exist. I've read as much. But I searched the all-knowing Google and didn't find the sources I sought. So at the moment, they remain outside my realm of knowledge. Therefore, I'd like to ask: What are your strategies? How do you handle problem developers or teammates? What are the reading materials discussing these issues that I'm looking for?

I supplied the dinner. Can you provide us with dessert?