Is it okay to use a language that isn't supported by your company for some tasks?

Question

I work for a company that supports several languages: COBOL, VB6, C#, and Java. I use those languages for my primary work, but I often find myself coding some minor programs (e.g. scripts) in Python because I find it to be the best tool for that type of task.

For example: an analyst gives me a complex CSV file to populate some DB tables, so I use Python to parse it and create a DB script.

What's the problem?

The main problem I see is that a few parts of these quick and dirty scripts are slowly gaining importance and:

1. My company does not support Python
2. They're not version controlled (I back them up in another way)
3. My coworkers do not know Python

The analysts have even started to reference them in emails ("launch the script that exports..."), so they are needed more often than I initially thought.

I should add that these scripts are just utilities that are not part of the main project; they simply help to get trivial tasks done in less time. For my own small tasks they help a lot.

In short, if I were a lottery winner to be in a accident, my coworkers would need to keep the project alive without those scripts; they would spend more time fixing CSV errors by hand, for example.

Is this a common scenario? Am I doing something wrong? What should I do?

Answer 1

You need to get the situation formalised as it shouldn't really have got to this point. However, these things happen so you need to explain to your boss that you created these scripts for personal use, but they've "escaped" into wider circulation. Admit (if necessary) that you were at fault for not bringing this to his attention sooner.

At the very least the scripts should be put under source control "just in case" - then at least if you aren't available (for what ever reason) your co-workers will have access to the scripts.

Then you either need to convince your boss that Python is the way to go for these or accept that you are going to have to re-write them in a supported language. If the cost of documenting the scripts and educating your co-workers in Python is lower than that of the re-write you might even win the argument.

Answer 2

I can't give you a full answer as to what you should do. I can only give a single suggestion you can use to start with:

Check the scripts into a repository that all (required) developers can access. But make very sure to make note of the fact that you've first written these scripts for your own purpose, i.e. to perform a task you'd been given. Then add that you're only checking in these scripts to allow others the advantage to use them.

After that you'll just need to see how other people respond to that.

Answer 3

I have run into similar problems where I work. I heard "What is PHP?" several years ago. They don't understand or care to learn anything outside of the MS stack. If python is the right tool for the job I'd just tell my supervisors about it and be ready for alot of comparison and explaining as to why python was the right choice. It will be frustrating, but I think most would agree python is a good choice for text manipulation.

Answer 4

The first thing you need to do is talk with the team and your boss. Right now, you have a huge truck factor (if you got hit by a truck, no one else would easily be able to maintain your scripts). It looks like having scripts to do these tasks are important, but it's also important that anyone who needs to can edit and maintain these scripts. You need to explain how using Python adds value - how it saves time, effort, resources, money, and so on.

Second, get it into the project's version control. Now. Nothing that you produce for a project should be outside of that project's version control, ever.

Be prepared for backlash - people typically don't like change. Running off on your own, using unsupported and unknown (to the team/organization) technologies was a bad idea, without consulting at least the other developers and determining the best (for the project, not just you) way of automating these tasks for everyone to use.

I think this is probably a good case of

It's easier to ask forgiveness than it is to get permission.

It sounds like you got the job done, but you are going to have to deal with the repercussions now.

Answer 5

My rule of the thumb is:

Anything that potentially impacts the work of others should be discussed with your peers and superiors ASAP.

But, if it's for you and you alone, as long as it doesn't do any damage to your firm's infrastructure or security, you are free to do as you wish to get the job done.

Answer 6

You have two options:

1. Make it a standard
2. Translate into a standard tool

Depending on the organisation #1 might be challenging (after all limiting the list of standard technologies avoids a combinatorial explosion of training and support skill requirements).

The second option would help your skill set, and you might be able to find third party (and likely open source with commercially friendly licences) to do some of the hard work. E.g. a search for "LINQ to CSV" should get some useful hits.

BTW, VB6's developer tools (IDE, compiler) is unsupported (not even security fixes) so it is likely the standard needs updating anyway. (VB6 runtime is supported as part of—and included in the install—of current Windows versions). This could perhaps be used as a helper to approach #1: the standard tool set needs to up a moving target because of supplier dependencies.

Answer 7

If you are given a task, and eithe the only way you can accomplish it on time, you don't really have a choice. I do think it is wise to let those in charge know what you are doing. You should not go outside the required source control (unless it just absolutely doesn't work at all?) testing and documentation.

Sometimes a company may have to let a single developer start looking into a new area of development. Unfortunately, the code may make its way into production faster than anyone else can get up to speed.

Answer 8

Well, I got to admit that working with 20 different languages stinks, A LOT.

You have a Bash script that calls Python script that calls Perl script that calls Java binary that calls C dll...

Then something hits the fan in the whole pipeline, and you go through - WTH IS DAT KODEZ? Especially in Perl... And debugging simple, say, encoding problem, turns into a nightmarish mess. You can't debug 5 out of 7 languages effectively, and it turns into a real pain.

Or you have to add a simple change, but you create 10 errors because Perl has gotchas, Java has gotchas, etc.

And that 7+ language chain starts one step at a time.

Tread carefully, here be dragons...

Answer 9

If those are tools you use for yourself, you are free to do anything that makes you more productive.

Actually, you should be encouraged to make and use such tools, which will ultimately became an extension of your arms.

Eventually, they will recognize the importance of having such tools, no matter what language they are written in, and will start to implement in their working environment.

Answer 10

When you are told to write code doing sth., the language is usually specified or implied (the rule in corporations).

But when you have to do some one-shot task, such as import data into DB, you are free to choose the tool that in your opinion fits the best, because you have to do something correct and fast, and the result is important, not the tools.

So, I would use that rule:

1) If you are told to do some task, such as data import, I would use the tools/language/etc. that would be the most convenient for me and would be the fastest for the task.

2) If you are told to write tool doing some task, such as import some data, I would discuss what language/tool to use with the manager (with exception when I use language that is implied standard, for example when company uses [almost] only Java).

3) If the task seemed to be one-shot, but it became repeatable, you should talk with the manager to change it from 1) to 2) and re-write from your preferred to company-supported language.

Answer 11

I suppose that you're not in a position to decide (or else you would not ask the question). What does your boss think about this issue? You should talk to him and try to convince him that Python is the way to go...

Of course, the issue is about what will happen when you leave. Not being able to maintain the code is probably a reason that's good enough to stop using Python. Or you can start educating your colleagues to this language...