Supporting developers who insist on using their pet language

Question

I've joined a team of around five developers building a microservice-based website, in a shop that emphasises autonomy and learning. However, it turns out one of the developers is writing "his" parts in his favourite new language, X.

I won't name X to avoid religious arguments, but instead list why I'm concerned:

• X is new, relatively obscure, and seems more aimed at writing command line utilities, not web service APIs
• it's evolving fast - apparently on going to document some older code, some base functionality had been removed, wouldn't compile in newer versions, so took a couple of days to re-implement it.
• there seems little prior art for how to approach a given task in X. An upcoming request is to add searching to API endpoints. He has no idea how to go about this, happily admitted each endpoint is implemented differently and "might re-write the whole thing". I like his can-do attitude, but is this really how to approach production code?
• the other developers are clearly uncomfortable with X despite some months of exposure. I've seen live site issues from deploying broken code when he was out. Yes, a conversation is needed around testing, but them not being able to spot showstopper errors in X is a red flag
• He's started adding plugins to other services, "to make them more X-like". Not sure yet what that means.
• etc. etc.

He's a pleasant and approachable person. He's not arrogant or argumentative or anything like that. He's just really, really into X, dropping it into every conversation, including to non-technical people. It's nice to see he's passionate, yet it's bordering on obsession.

I'm his new line manager, concerned about both the low bus number and the clear day-to-day risk from brittle, hard-to-understand bags of X.

While I could ask him to stop using X, it clearly wouldn't go well, and anyway I want my team to be autonomous and happy, building them up, not shutting them down. And yes, I am setting time aside to learn what X I can. Perhaps I'll see the light and I can help him that way.

How can I handle the risk to the project presented by X? Is X itself even really the problem?

Answer 1

I suggest you put the question up for discussion to the team. Present your concerns at the next team meeting and ask what they think about them.

Since they sound like valid concerns I would imagine you'll get support from the other developers.

Make sure the discussion stays professional and keep an opened mind. Focus on how using X affects the rest of the team. This way the developer will be less likely to become defensive and when he realizes how his use of X affects the rest of the team it will be very difficult for him to simply dismiss their concerns.

Answer 2

How can I handle the risk to the project presented by X?

To address this, I am going to use your own words:

it's evolving fast / unstable - on going to document some older code, he found some base functionality had been removed, wouldn't compile in newer versions, so took a couple of days to re-implement it

AND

the other devs are clearly uncomfortable with X despite some months of exposure. I've seen live site issues from deploying broken code when he was out. Yes, a conversation is needed around testing, but them not being able to spot showstopper errors in X is a red flag

This language is obviously not very mature. Building your empire on quicksand is not a good plan, and I think you know that. As the manager it is up to you to manage the risk, and set the standards.

Is X itself even really the problem?

I think the problem may be that there are no standards set in your group. I would suggest you and your team agree on what languages are going to be used and then move forward.

Any new technologies should be presented to the team before they are used in production. When a new technology is presented, the team then votes on the validity of the technology. This way there isn't a single bad guy should X get voted down.

Also, and this is really important to you: You have to be able to support the code when a developer leaves. If you allow one off's, this becomes more difficult for you. You also might wish to do some research on this languages popularity and usage to make sure you can hire new help when the time comes.

Answer 3

I'd be very, very concerned about this.

If he gets hit by a bus tomorrow, or decides to leave tomorrow, then you currently have:

• A massive cost, both time and money wise, of finding an expert in X to replace him;
• A team that doesn't understand any of the code he's written;
• A team that can't reliably even deploy any of the code he's written;
• Code that is likely to only work with a specific, unknown version of X, and break with future versions.

You'll then have your superiors raining down on you like a ton of bricks asking why the hell you let this happen in the first place.

You say he's a nice guy - just over-enthusiastic, so I'd put these problems to him, and the whole team in general. Ask for their thoughts on solutions. Emphasise that this isn't a punishment or anything they've done wrong, just a potential problem you all need to solve. Emphasise that this isn't a language driven problem, it's a business driven problem. Make sure you're open to criticism if your understanding of any of the above points are incorrect, but if not, you need to stand your ground in making sure:

• No new code is written in X;
• Preferably, you have a longer-term plan to migrate existing code he's written in X to another language.

That's not to say he shouldn't be instrumental in picking another, more suitable language that can be used, and that's not to say he needs to abandon X entirely. Perhaps you could set up workshops or presentations where he demonstrates new patterns / paradigms in X, and how they can apply to (relevant language for the workplace.) Perhaps he can search for another language that's more mainstream, but has more of X's properties.

However, if I were the team lead I certainly wouldn't budge on allowing such a language to be used in a business critical context.

Answer 4

Hard no.

Pet languages, or even excessive numbers of languages, getting introduced into a project make it completely unmaintainable in the long term. When the developer leaves, you'll end up with the code in their pet language in whatever status they left it in, and a pile of workarounds in the other components to get things done without having to change the code that nobody understands. I speak from experience on projects where this has happened.

Answer 5

Absolutely not! Entire companies have died because they picked the wrong language in which to write their codebase. If the language dies, becomes unpopular, or leads to intractable scalability issues, the code dies too. Can you afford to rewrite it?

When you need to completely rewrite a piece of software in a different language, you will be a sitting duck, because you can't release a new product until the rewrite approaches feature parity with the old product. If it's possible to avoid a rewrite, you should!.

Case studies:

• Twitter suffered from frequent "Fail Whales", and eventually rewrote their Ruby on Rails server.
• WordPerfect got crushed by Microsoft Word. While there are many business reasons for their downfall, part of their problem was that much of the code was written in assembly language, making it hard to port to Windows.
• John Ousterhout, who invented the Tcl language, founded Ajuba Solutions, a company whose software was mainly written in Tcl. While there wasn't really anything technically wrong with Tcl, it just wasn't that popular. His company had a few talented and dedicated Tcl developers, but it was difficult to hire. Eventually, the company got acquired, the codebase was abandoned, and the majority of the developers lost interest in working after the acquisition.

No single programming language excels at everything, and you do want developers to be able to pick the right tool for the job. That said, there have to be some constraints when introducing languages into your company's codebase. Some criteria to consider:

• Enough of your team has to be fluent in the language so that there can be code reviews and multiple maintainers.
• You have to be able to hire programmers who are willing to work in the language and its ecosystem. (And you have to be able to tolerate the kinds of developers who tend to gravitate towards those languages.)
• The language should be versatile enough to make the investment worthwhile.
• You should recognize and accept the risks associated with the language (e.g. frequent incompatible changes, frequent security vulnerabilities, quality of the standard library, scalability, memory safety, readability, error-handling strategies, unintuitive behavior, etc.)

Sometimes there may be mitigating factors to the risk of choosing a more obscure language. For example, a language might interoperate with other languages on a Java Virtual Machine or Microsoft's Common Language Runtime. Or the language (e.g. Swift) might be designed to interoperate with another (Objective-C). Interoperability at least gives you a migration path that doesn't leave you stranded during a rewrite.

You might consider granting more flexibility for throwaway code or prototype code. Sometimes the ability to prototype rapidly trumps the long-term concerns listed above. Beware, though, that prototypes can have a tendency to grow into permanent solutions.

In your particular case, you said that you have a microservice-based website, with parts of it implemented in another language. Even if you're not betting your company's future on language X, unnecessarily mixing implementation languages is harmful to building a cohesive architecture. (The fact that one developer has total free reign over one part of the project raises a red flag about the lack of architectural design at your company.) Having to learn the language is not the only barrier; it also increases the complexity of the tools for developing, building, static analysis, testing, and deployment. Then, there are also more libraries that you'll need to patch in the future. You also mentioned that the language introduces incompatible changes from time to time, which indicates that it is experimental-quality, not production-quality, software. If the entire team bears these costs just because of one developer's personal preference, everyone is going to resent that developer, whether secretly or openly.

In general, the choice of programming language (or, for that matter, programming frameworks) has to be a team decision, and should not be made by a single lone wolf or rock star developer. It sounds like your team is not comfortable with language X, and the group sentiment should be a good reason to require the maverick developer to stop using it.

Answer 6

This is one of the few things were I think a manager should put his foot down and not give in. What the developer is doing will hurt the company in the long run. And it doesn't matter what X is -- all that matters is that your company does not have a lot of expertise in X, and it will be hard to attract expertise in X.

Your developer is wrong that X is the right solution. Not because it's the wrong language for the project, it's the wrong language for the company.

Tell your developer that his actions are not the actions of a senior developer, and even below expectations for a normal developer. Make it clear that his actions are not going to reflect well in his next performance review, and if he continues in this way, if will effect his chances on promotion and bonusses.

Tell him that you expect developers to act what is best for the company and that you're working on a product which is expected to be developed and maintained for a long time, and not just by him. Every current and future developer should be able to work on the product, without first having to learn a different language. Tell him that you expect good developer to consider what the situation will be next year, five years and ten years from now. And that decisions made today will influence the future.

In other words, tell him to leave his pride at the door and become a team player.

Answer 7

Is X itself the problem?

No.

X is not the problem... for every value of X

This is a management problem. As a new manager, you landed a tough one.

You problem is that you

1. have a very enthusiastic programmer who you would like
   to redirect into a more productive employee.
2. You suspect that if you tell him he can't use X you will have to replace him because he will leave
   He's telling non-tech people about X, so you're right (it is currently religious for him)

Explain how the world works:

As a new manager I love to let people use what they are passionate about. In your case that is X.

The problem is that we get graded poorly when things break. This reflects poorly on the whole team.
A few times the build has broken when you weren't here. I'm trying to learn X so I can join you. While it is interesting, I can't devote a enough time to it right now.

How we can keep X without making everyone look bad?

Because there aren't an established set of best practices for what we do, we cannot standardize on a language as new as X. This is why we have had problems with it even though you are an expert in it.

So... how do we address this in the short term?
Are there more stable builds that can be used? How can we ensure that nothing breaks and no one else has to stop what they are doing to learn X?

Change "the build has broken" to the most obvious problem caused by X being present.

Give him time to respond. If he doesn't respond with much, let him go back to his desk (repeat the question before he goes to get him focused on "how").

Answer 8

I think you're approaching the problem from the wrong perspective.

You are turning it in our pet language vs. his pet language problem. Languages are only tools, quite universal one, so their choice is a side issue.

The real problem is that you have a total chaos in team. It looks like everyone can do what he want, choosing any tool, even those he's really not familiar with. This is what you need to address.

Having only one person in team being able to support any relevant part of the project is simply insane. Either at least 2 people in team should master X to the extend allowing the maintenance, or X must go away.

The fact that your X-pet developer is not sure how to implement one of the crucial aspects in X means, that even he doesn't master it to reasonable extend. It's a moment to say sorry, but your company is employing people to do the job, and not to have fun learning new tools.

A considerable solution might be to allow him to develop experimental tools/features in up to, say, 20% time. Totally banning X might be counterproductive, if you want to keep this guy in your team (and you most likely will, since team of 5 turning into team of 4 in productive application will surely not help maintaining the app).

Answer 9

As others have said, this situation should not be allowed to continue. It does indeed sound like the fundamental answer is going to be of the form "No, sorry, you can't use X." And you are well within your rights to say that. Your worst case scenario is this dev gets upset and quits. That would be sad, but is his perogative and your answer should probably still be "No X."

As well as the problems already identified, one dev going off on their own with a pet language

• makes effective code review impossible
• makes interoperability with the work of other devs difficult
• requires code duplication for all common utilities used by X and not-X (particularly those that are bespoke and not found in the X standard library)
• Reduces team cohesion, particularly between X and not-X factions.

Perhaps a more helpful response than just saying "No X" in a loggerhead fashion is

• Ask what in particular about X is desirable. If genuine, investigate whether some of these advantages could be used in a more standard language. (You'd be surprised at how many trendy features make it to new versions of old languages like C++ and Java, or at least get 3rd party library support)
• Invite the dev in question to take the lead (although not without oversight) in developing what useful lessons can be learned from X and transferring them to Y best practices.
• Collate some data to defend your point. E.g. it may help being able to say "We've already spent _% of X dev time just dealing with the instability of X, compared with _% in updating for changes to Y" or "Integrating and debugging X code has reduced the performance of the team overall by _%.
• Consider whether there are underlying causes of this issue beyond the language preferences. For example, if this reveals a general team culture of isolated devs working on isolated features, do something about that. It may be, for example, that introducing pair programming could help address the roots rather than the symptom.

---

As an aside, it is possible for the right answer to be "yes, let's all transition to use X." That is not the case here, very compellingly because X is small, obscure, unstable, and a poor fit for the problem. However, suppose for example you're an Android shop and you have one dev agitating to move from Java to Kotlin, because Google have recommended transitioning from Java to Kotlin and promised that Kotlin will be better supported going forward than Java. Ultimately, they're very plausibly right.

Many of the same concerns apply. You'll need to worry about training, about code compatibility, about how members of your team respond, and potentially even the risk that one of your devs so dislikes the change that she decides to quit. Meanwhile, many of the same mitigations would apply: authorising invested people to spearhead it, collating data about why the decision has been made, listening to various stakeholders, etc.

Answer 10

I'm the question author. This has been popular! Re-discovering this two years later, will give an update.

At first accepted https://workplace.stackexchange.com/a/140159/106726 as the answer - which TBF the developer had started doing on his own. But a couple weeks later he handed in his notice. He made clear this wasn't because of me, or X, but the company in general.

So, time to replace X, right? Nope. The business (read CEO / CTO) weren't interested in migrating, even though I was clear X was holding the company's products back, was a serious source of risk, and made multiple proposals for moving the product forward. (Anyone familiar with "brochure over functionality" startups should recognise this).

We limped along using X. We could compile and deploy it, and as I grew the team, a couple of talented engineers learned enough to make various changes. I left things open for if they became fans, but no. The X-community infighting killing the framework we used didn't help. I made sure that the rest of the stack had no X and used standard approaches. We worked around it when needed.

I left the company several months ago. As far as I know, they are still using X for a business-critical, customer-facing web API.

EDIT: oh go on then. X is Rust.

Answer 11

No, language X itself is not really the problem. What you've described here are the symptoms of a much deeper problem that will affect all the other systems your team produces as well: the team isn't really working as a team but instead as a bunch of disconnected individuals.

Your instinct that you "want [your] team to be autonomous and happy, building them up, not shutting them down" is correct; you need to solve this problem by coaching the team to fix it. I would start with trying to remove the clear code ownership that's happening where the code written in language X is "his" code. It's the team's code, and the team as a whole needs to be responsible for maintaining it and extending it.

You might start with how stories (or whatever your equivalant) are assigned. Ideally all members of the team should be regularly working on all parts of the system, rather than specific parts of the system "belonging" to particular developers. It's fine if you have some developers who are experts in a particular technologies or parts of the system while others are not, but there should be nothing in your system where there aren't at least two developers who feel they know that part well enough to be the technical lead on any particular story where it's a major component.

Pair programming and just asking for help are typical solutions for spreading knowledge. Extreme Programming handles this by allowing anybody to pick and be the lead on a story, no matter how much or little they know about it, and relies on developers not being allowed to say "no" to requests for help with that story, allowing that developer as he gets his help to learn all the gory details necessary to getting the story done. (Story assignment in XP is actually a project management function: the developer managing a story for that iteration is responsible for making sure it gets done, finding all the resources necessary to do so. This will typically result in the developer having a reasonably deep technical understanding of the story by the end of the iteration, whether she started out with that or not.)

So explain to your team that you're happy with using language X, or anything else, if the entire team has a consensus that it's a good idea and agrees that if the developer in question is kindnapped by aliens the team will carry on just fine without him. It's then up to that developer to sell his technical ideas within the team. Make it clear that even if the team doesn't agree to make X the primary development language for all new features this doesn't mean it can't be used at all; perhaps it could be used in just certain smaller areas in order to test it and gain experience with it. Encourage regular reviews both of how language X is working out where it is used and of specific subsystems (whether using language X or not) regarding how well they're working, what kind of problems are typically coming out of it, and how these can be mitigated.

Answer 12

Building on other answers, I agree that languages/technologies to be used in the project should be positively selected by the team before being used (excepting possibly a trial or test case for feasibility, with no promise or critical-path to be used in the project itself).

I worry that that wasn't done, and trying to bring the topic up for discussion with the team now would result in no one willing to confront the rogue programmer and say "no" (following from the fact that even the manager is currently fearful of taking that step).

Consider the following as a possible way to solve this: Have a "reset" meeting, where the team will jointly select/approve technologies to be used and supported in the project. Act as though the project was being newly started, no languages had been selected to date, and you're starting from a blank slate. Now the burden of proof is on getting to "yes" for the new language (as it should be), instead of the "no" (where it currently seems to be).

Answer 13

You should make it obvious for the higher-ups and the team that X in its current state is a problem, because apparently there is currently no understanding that this is the case. Tell everyone that the team needs at least two X experts, in case one of them calls in sick. Ask for a training in X for the whole team. Every time the project breaks because of an incompatible X update, or a trivial bug which wasn't found because testers are not familiar with X, start a discussion on how to prevent such mishaps in the future.

Either the company will decide to drop X, or they decide to go all-in and make X widely adopted. In either case, the problem of X being a "pet language" will disappear.

And don't blame the developer for "bringing X upon us". Approachable and passionate developers make great company assets and great colleagues. It's not their fault the management bought into their idea of adopting X which they thought was brilliant, without evaluating the risks.

Answer 14

I think you need to have a discussion with the team on this language. Let the developer to present the language first, hear the advantages the language can give as well as what disadvantages language has. Bring up your concerns about stability, compatibility, etc. Take a look on the track record of who developed the language (for example Microsoft is known to kill the technologies that they were promoting shortly before kill announcement (see multiple iterations of Windows Phone, Silverlight, etc.)) Encourage other developers to provide their thoughts.

If discussion turns against X and you do not really want to entirely shutdown that developer or it would get even you can make a decision on to keep the language to a one off project and see how is it going to go and have a second round when the project is complete (honestly, this is what I would do no matter what (unless X is a complete trash): let a small one off project fully be done in that language and have a second round).

PS: sometimes some really "strange" and uncommon languages can give a huge advantage in some projects: http://www.paulgraham.com/avg.html (Article is almost 20 years old so you can ignore the technologies and languages but think more about a concept)

Answer 15

In top of the answers

I think the problem is about confidence.

your developer is confident of using X and afraid of using any other language he is not so good at.

probably a training in the capabilities of your Y language may give him some confidence in using Y

Answer 16

Consider the possibility that your developer (the one who really likes X) is on the autistic spectrum, or at least has autistic traits. The obsessive focus on one thing, talking about it all the time, may indicate that this person has some sort of condition, which makes it difficult for him to approach the matter objectively.

The reason why I'm saying this is because, if this is the case, you may need to handle the matter differently than you would have with a neurotypical (i.e. "normal") person. It doesn't mean that said developer is less suited for the job.

My employer pays me to write software that we sell to customers. They don't pay me to muck along and do whatever I like. I like to play video games, for example, but that doesn't bring in any money.

Similarly, a non-established language like X appears to be causing more problems than that it is solving. It means that the productivity and performance of your entire team is at risk, because of one guy who wants to do things differently.

If using X can be shown to have a net positive effect on productivity and performance, keep it. Otherwise, make clear to your developer that he needs to separate hobbies (his fascination with X) from work (what pays his wage).

At work, I'm experiencing a somewhat similar scenario. In my department, there are basically two main pieces of software that were written a long time ago, and haven't really been updated. Anaemic object model, poor coding practices, old-fashioned technologies and frameworks... The list goes on.

And while I have the experience and knowledge to introduce new concepts, like domain-driven design, micro-services and single-page applications, I also need to consider that the other developers will need time to catch up. It's a delicate balance that needs to be struck.

But in the end, you need to focus on the well-being of your entire team, not its individual members. You cannot make everybody happy. It's a company, not a democracy. It's imperative to listen to people, but it's equally imperative to make a decision and ensuring that everybody sticks to it. Otherwise, don't be a team leader.