Our decision to restrict what we use for developing internal tools

August 6, 2017

A few years ago, we (my small sysadmin group) hit a trigger point where we realized that we were writing internal sysadmin tools (including web things) in a steadily increasing collection of programming languages, packages, and environments for doing things like web pages and apps. This was fine individually but created a collective problem, because in theory we want everyone to be able to at least start to support and troubleshoot everything we have running. The more languages and environments we use across all of our tools, the harder this gets. As things escalated and got more exotic, my co-workers objected quite strongly and, well, they're right.

The result of this was that we decided to standardize on using only a few languages and environments for our internally developed tools, web things, and so on. Our specific choices are not necessarily the most ideal choices and they're certainly a product of our environment, both in what people already knew and what we already had things written in. For instance, given that I've written a lot of tools in Python, it would have been relatively odd to exclude it from our list.

Since the whole goal of this is to make sure that co-workers don't need to learn tons of things to work on your code, we're de facto limiting not just the basic choice of language but also what additional packages, libraries, and so on you use with it. If I load my Python code down with extensive use of additional modules, web frameworks, and so on, it's not enough for my co-workers to just know Python; I've also forced them to learn all those packages. Similar things hold true for any language, including (and especially) shell scripts. Of course sometimes you absolutely need additional packages (eg), but if we don't absolutely need it our goal is to stick to doing things with only core stuff even if the result is a bit longer and more tedious.

(It doesn't really matter if these additional modules are locally developed or come from the outside world. If anything, outside modules are likely to be better documented and better supported than ones I write myself. Sadly this means that the Python module I put together myself to do simple HTML stuff is now off the table for future CGI programs.)

I don't regret our overall decision and I think it was the right choice. I had already been asking my co-workers if they were happy with me using various things, eg Go, and I think that the tradeoffs we're making here are both sensible and necessary. To the extent that I regret anything, I mildly regret that I've not yet been able to talk my co-workers into adding Go to the mix.

(Go has become sort of a running joke among us, and I recently got to cheerfully tell one of my co-workers that I had lured him into using and even praising my call program for some network bandwidth testing.)

Note that this is, as mentioned, just for my small group of sysadmins, what we call Core in our support model. The department as a whole has all sorts of software and tools in all sorts of languages and environments, and as far as I know there has been no department-wide effort to standardize on a subset there. My perception is that part of this is that the department as a whole does not have the cross-support issue we do in Core. Certainly we're not called on to support other people's applications; that's not part of our sysadmin environment.

Sidebar: What we've picked

We may have recorded our specific decision somewhere, but if so I can't find it right now. So off the top of my head, we picked more or less:

  • Shell scripts for command line tools, simple 'display some information' CGIs, and the like, provided that they are not too complex.
  • Python for command line tools.
  • Python with standard library modules for moderately complicated CGIs.
  • Python with Django for complicated web apps such as our account request system.

  • Writing something in C is okay for things that can't be in an interpreted language, for instance because they have to be setuid.

We aren't actively rewriting existing things that go outside this, for various reasons. Well, at least if they don't need any maintenance, which they mostly don't.

(We have a few PHP things that I don't think anyone is all that interested in rewriting in Python plus Django.)


Comments on this page:

By Twirrim at 2017-08-06 11:57:42:

We've done the same thing both in my current job (one of the teams in Oracle's Bare Metal Cloud service), and at AWS. It basically came down to shell scripts, python and java. The languages involved are mature and get the job done. It's rare to find something that can't be solved via some combination of the three (plus system binaries, naturally).

Even when you're dealing with fairly large teams, writing tools in the same subset of languages makes life a lot easier for everyone. There's less effort required on all parties to have to go pick up and modify something written by other people in the team, and time can be spent creating useful common libraries to be shared among the team.

There ended up being a bizarre, and huge argument at my last place, when one co-worker decided to start re-writing tools in Go, arguing that the reduced startup time was invaluable. It knocked a second or two off the run-time, but it was a tool that was rarely used (on the order of every month or two), and in the worst case scenario was used in a loop a couple of dozen times. A case of pointless optimisation, plus the added load of now having dozens of staff members having to learn Go, and how to write tests in it (maybe 3 people in the team had even fiddled with Go). Management never cracked down on it, and the tool never got through code-review as a result :D Stayed in that situation until the co-worker eventually changed departments.

Written on 06 August 2017.
« I've been hit by the startup overhead of small programs in Python
There will be no LTS release of the OmniOS Community Edition »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sun Aug 6 02:03:10 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.