5 ms·

> I've seen companies not using source control > ...all changes are being made directly on the production servers via SFTP I know this used to be common, but

by Reedx 8y ago

> I've seen companies not using source control > ...all changes are being made directly on the production servers via SFTP I know this used to be common, but recently? Curious how often this is still the case.

cr0sh 8y ago
Hey, at least they're using SFTP - you know, for the security! /seriously, though - I...hope this isn't being done any longer - but I bet it is. Sigh...
Bartweiss 8y ago
At my first (very small, research-group) employer, I was the one to introduce source control. Another company I saw ~4 years ago had Git, but no one knew how to use it adequately so "lost code" was still a regular event. I haven't seen it since, though; lots of people frightened by and badly misusing Git, but they mostly manage to keep code histories intact. Having no testing/staging environments remains pretty common, along with its cousin "production work happens on staging". Partnering with not-primarily-software companies and asking about staging infrastructure, you har that regularly. And yeah, SFTP/SCP/SSH is a standard push-and-deploy approach in places where that happens.
frosted-flakes 8y ago
I have seen it recently. I did my best to change the practice before I left the company, but was mostly unsuccessful. Given that they were still running some of the spaghetti-code PHP scripts that were written in 1999 and still used PHP4 in new development they were stuck in the stone ages. To give a little perspective, support for PHP4 ended in 2008, so they had almost a decade to update, but didn't.
- HenryBemis 8y ago
  "If it ain't broken, don't fix it". And then one day the server goes boom, the backup was incomplete, and everyone is trying to find the usb flash disk with Spinrite in it. Meanwhile the CEO who was rejecting the €¥$£ in yh budget since 2000 is angry at everyone! Oh the times I have seen this!!!
  - taurath 8y ago
    Its both the CEO's fault for either not understanding or not hiring someone who properly understands the risk they're taking on in their tech stack, and whoever's job it was to understand the risk. Part of being a responsible engineer (or IT manager, etc) is to be able to say "no" to new things and to explain that a bad day can and will take you down.
  - frosted-flakes 8y ago
    Oh, now that you mention backups, that was a nightmare too. Thankfully, the production database was backed up daily on magnetic tape and stored offsite, but the code was generally edited live on the server, and backups consisted of adding ".bak20190402" to the end of the file. Needless to say, losing code wasn't uncommon. This was for a 100+ year old company with millions of dollars in annual revenue that was owned by the government. So, yeah. 100% the IT director's fault, who'd been there since the early 90s.
seanwilson 8y ago
> I know this used to be common, but recently? Curious how often this is still the case. Several times within the last year for me. Not all companies have big tech departments with knowledgable developers advocating modern best practices. Some big internal systems can start out from someone internal applying some basic self-taught skills for example. To be fair, the jump to using Git (and especially dealing with Git merge conflicts) is scary. It can be a hard sell to get people to move from a system they already completely understand and have used successfully for years, even if their system looks like ancient history to us. Literally heard "...but my IDE already automatically uploads to FTP on save, I'm usually the only usually one editing it and I already know what I changed" last week.
drablyechoes 8y ago
Way too common. So many clients I've dealt with have a deployment workflow that is some variation of this.
user5994461 8y ago
On the one hand, source control is really the most basic thing you can find anywhere. It's really hard to find an actual development shop without source control. On the other hand, outside of a tech company and with less than a dozen developers, don't expect to find any source control. Consultants see a lot of this shit, they work in all industries including where developers don't exist, with a lot of thrown away projects. Funny thing. Git probably made it worse in recent years by being impossibly hard to use.
z3t4 8y ago
Its nice to have a source code history to see why and when something was changed. But a lot of tooling is usually to treat the symptoms of complexity.

by Reedx 8y ago

cr0sh 8y ago

Hey, at least they're using SFTP - you know, for the security! /seriously, though - I...hope this isn't being done any longer - but I bet it is. Sigh...

Bartweiss 8y ago

At my first (very small, research-group) employer, I was the one to introduce source control. Another company I saw ~4 years ago had Git, but no one knew how to use it adequately so "lost code" was still a regular event. I haven't seen it since, though; lots of people frightened by and badly misusing Git, but they mostly manage to keep code histories intact. Having no testing/staging environments remains pretty common, along with its cousin "production work happens on staging". Partnering with not-primarily-software companies and asking about staging infrastructure, you har that regularly. And yeah, SFTP/SCP/SSH is a standard push-and-deploy approach in places where that happens.

frosted-flakes 8y ago

I have seen it recently. I did my best to change the practice before I left the company, but was mostly unsuccessful. Given that they were still running some of the spaghetti-code PHP scripts that were written in 1999 and still used PHP4 in new development they were stuck in the stone ages. To give a little perspective, support for PHP4 ended in 2008, so they had almost a decade to update, but didn't.

HenryBemis 8y ago
"If it ain't broken, don't fix it". And then one day the server goes boom, the backup was incomplete, and everyone is trying to find the usb flash disk with Spinrite in it. Meanwhile the CEO who was rejecting the €¥$£ in yh budget since 2000 is angry at everyone! Oh the times I have seen this!!!
- taurath 8y ago
  Its both the CEO's fault for either not understanding or not hiring someone who properly understands the risk they're taking on in their tech stack, and whoever's job it was to understand the risk. Part of being a responsible engineer (or IT manager, etc) is to be able to say "no" to new things and to explain that a bad day can and will take you down.
- frosted-flakes 8y ago
  Oh, now that you mention backups, that was a nightmare too. Thankfully, the production database was backed up daily on magnetic tape and stored offsite, but the code was generally edited live on the server, and backups consisted of adding ".bak20190402" to the end of the file. Needless to say, losing code wasn't uncommon. This was for a 100+ year old company with millions of dollars in annual revenue that was owned by the government. So, yeah. 100% the IT director's fault, who'd been there since the early 90s.

seanwilson 8y ago

> I know this used to be common, but recently? Curious how often this is still the case. Several times within the last year for me. Not all companies have big tech departments with knowledgable developers advocating modern best practices. Some big internal systems can start out from someone internal applying some basic self-taught skills for example. To be fair, the jump to using Git (and especially dealing with Git merge conflicts) is scary. It can be a hard sell to get people to move from a system they already completely understand and have used successfully for years, even if their system looks like ancient history to us. Literally heard "...but my IDE already automatically uploads to FTP on save, I'm usually the only usually one editing it and I already know what I changed" last week.

drablyechoes 8y ago

Way too common. So many clients I've dealt with have a deployment workflow that is some variation of this.

user5994461 8y ago

On the one hand, source control is really the most basic thing you can find anywhere. It's really hard to find an actual development shop without source control. On the other hand, outside of a tech company and with less than a dozen developers, don't expect to find any source control. Consultants see a lot of this shit, they work in all industries including where developers don't exist, with a lot of thrown away projects. Funny thing. Git probably made it worse in recent years by being impossibly hard to use.

z3t4 8y ago

Its nice to have a source code history to see why and when something was changed. But a lot of tooling is usually to treat the symptoms of complexity.