How I failed to teach a hydrologist a version control system
Why scientists and engineers resist learning new software development tools
In the 1990’s we weren’t using any version control system. We just put the program files in a directory and edited them there. We were backing it up often, so you’d get directories named like “hydrognomon-1995-06-17”, or, worse, “hydrognomon24”. Sometimes a person would give his folder to another person to continue it, and sometimes we’d end up not knowing who had the latest version. That was a hydrology research team in a university, so it wasn’t surprising we worked this way—but software companies were already using version control systems.
Eventually, around 2000, I convinced the research team to start using CVS. There was now an official, central repository of code, and each person checked out his own copy from there, and whenever he made a change, he checked it in. Now we always knew what was going on, and we knew the history of changes to our code.
But CVS was a pain, and when, a few years later, Subversion became popular, the team, under my guidance, switched to it. Subversion was much easier to use than CVS.
In 2009, distributed version control systems became fashionable, and I decided we should switch to Mercurial. It was harder to learn than Subversion, but it was more powerful and much faster. On that occasion, three members of the team, who were programmers, did learn Mercurial; but one member, a hydrologist who could also program, did not seem to intend to learn it. When I asked him why, he said, half-jokingly, “because you are going to change it again”. (He was right.)
Why am I telling this story? Because it goes right into the heart of the problem. We software developers learn new tools all the time; it’s our job, they make our work easier or more effective, and we like doing it—otherwise we wouldn’t be programmers. Scientists and engineers dislike learning new software development tools, programming languages, programming techniques, libraries, etc. They like improving their science and engineering skills, not their programming skills. As a result, they stay behind.
What is the solution? Should they just write prototypes and leave the actual programming to programmers? This doesn’t really work well, but it’s a story for next time.