Arguing for Software

Young, earnest, and eager developers are often overcome by desire to swap out an old boring piece of software for a new, exciting replacement. Often it goes something like this:

“nobody is using [REDACTED] anymore, we should switch to [NEWHOTNESS] instead”

or

“[BIGGER, BETTER COMPANY] uses [NEWHOTNESS] instead of [REDACTED], this place is a joke”

We all know that there are of course also plenty of reasons to keep up to date when it comes to technology, most of which are economic in nature. Very often, however, we allow our experience to skew our objectivity when it comes to selecting a piece of technology.

Shouldn’t it be precisely our experience that forms our decision making? Yes, but only if we are honest about the actual breadth of our experience.

Strong personal preference seems to coincide with narrowness of experience. Take source control systems, for example. If you started working in software in the last five years, there’s a good chance that you’ve only ever used Git. Everyone you know uses git, and you cannot remember a time when they did not. Further, you’ve heard anectdotes from your friends about the dark days before git when programmers were forced to breathe Subversion fumes for weeks on end and were utterly unable to collaborate in any meaningful way. You know all the commands, you’ve written your own git commands. You are a git ninja.

Then, you get hired at a company that uses Perforce. It is positively baroque, you think. It seems obvious what a tremendous improvement it would be to throw out Perforce and replace it with Github Enterprise, and furthermore it is a tremendous inconvenience to have found yourself unable to capitalize on your enormous git experience; your scripts go unused.

If it sounds like I’m mocking git zealots, it’s true, I am. If you’re offended, you deserve it as much as I did when I got mocked for behaving in exactly the fashion I’ve described, and I did it many, many times.

It wasn’t until years later when I sank into the ugly sausage-making of management, forced to endure the same demands from dozens of little younger copies of myself, that I discovered what an ass I’d been. I also, confoundingly, found that almost all good change came from ideas that developers, so noone should ever be ignored.

The developers who were able to affect change most effectively seemed to share a remarkable knack for detached objectivity, and usually presented their conclusions in the form of well-reasoned papers instead of bitching round the scuttlebutt. They also managed to conceal their personal preferences completely, focusing on dollars and man-hours instead of vague claims about developer productivity.

From one of them, I learned a very simple but profoundly effective strategy:

Pretend you hate git. Just loathe it. Its myriad confusing, overlapping and impossible-to-memorize variants of commands. The preposterous cost to license the enterprise versions of ostensibly free software. The countless ways to wreck your local repository. Even it’s name sends venom to your teeth. It is, in short, dreadful.

Now, construct a reasoned argument why your company should make the switch. If you can’t do it, you never had a real theory to begin with. If you can, you’re probably on to something, and the odds of having your argument taken seriously improve.