I was just told at my day job that the team will not be using VC for tracking production analytics code because "using git is over-engineering".

There's a set of projects in an adjacent work group that does not use version control. Instead, they create snapshots at various stages of development (before certain formal reviews). These snapshots are fine, actually they're useful, but they don't replace version control. I had a chance to explain and demo git to one of them, who'd written some 10k lines of code between snapshots, to explain how git could help him manage his work better (easier to try things and roll them back, as the primary one). This helped, he had started to use it though I don't know if it's spread yet.

Fortunately there is no opposition to version control in their group, it's just momentum keeping them from changing.

This reminds me of the comic which has a machine gun salesperson trying to sell to a medieval king who says "I can't be bothered with that, I have a battle to fight!"

> using git is over-engineering

Their compass to locate "over-engineering" is a bit off track. Engineering starts after you have put your artifacts in git or any other VC :-)

Time to start the job hunt.

I can't recall if it was in Prag Prog but it's one of my favorite Andy Hunt quotes... "Change your team or change your team"

Sometimes I think "software engineering is too immature for there to be a rigorous standards body and professional engineering certifications" and then I see shit like this and wish there were a way to punish people for gross negligence.

My business partner worked at an education-related company you've almost certainly heard of about six or seven years ago. When he started he ask where the defect tracking system was. The guy he was talking to pointed and said, "Go ask Susan. She has a spreadsheet." It was, as you can imagine, pretty much all downhill from there.

was this education-related company, related to moocs ?

Not that I'm aware.

That boggles my mind. Maybe it is just where I have worked all of my 35 years, but source and bug tracking were always at the forefront of every engineering effort. Hardware and software, didn't matter. Code and documents. Requirements and design. Everything was tracked. If you had a printed requirements document in your hands, you could look up what the current working version was, and check that against the version printed on the first page. (yes, we used to print documents, back in the days of VT220 terminals....)

Who in their right mind works without version control? Who would want to? And version control has just gotten better and better over the years. I started with SCCS -> CVS -> SVN -> GIT (with a couple of side treks into Perforce and Clearcase). Currently using Bitbucket/Jira, but have also recently used raw git/gerrit. (The organization makes the choice)

I've seen this as well. It was also super critical bootstrapping code/config. It is so embarrassing I won't say who. But not having code in source control is still a thing. Sometimes if it's in source control, someone has still edited something on production and not checked it in.

> Sometimes if it's in source control, someone has still edited something on production and not checked it in.

I worked at a large fintech company that had serious problems with this. About the only hope we had for mitigating it was moving all the services to run inside docker containers and of course ban developers from accessing the systems directly.