Comment by nayuki
7 years ago
I am impressed you stood your ground on a technical quality issue. One thing though - if you find yourself in this kind of situation in the future, try to inform your employer of the technical risks (data corruption, data loss, lack of accountability when multiple people edit files), and get them to sign off in writing that they agree to the risks. That way, they cannot blame you if the system ever becomes screwed up.
I'm I the only idiot who would back up the files and make the change, and thinks that the hero contractor's wrong here? Version control is nice, but it's not a prerequisite to shipping, and not using one isn't "extremely dangerous and irresponsible" unless you're working on control systems at a nuclear power plant.
Maybe you shouldn't make the change until you have a Selenium suite, automated rollback, blue/green deployments, a bulletproof status page, and an on-call rotation with a regularly tested runbook. Maybe we should just sit on our hands and make internal improvements until things are perfect.
Reductio ad absurdum. I shoved a code base into version control and set up a super simple but safe deployment strategy. No fancy anything. It put off non critical development for a day and made development faster because I could make sure my code worked locally and not just on the live site.
Some companies value hyper-compliance, some companies value employees that speak up in cases of negligence. You have the freedom to choose your own preferences.
Furthermore, it IS possible to respectfully communicate your concerns and position without being a heroic jackass. My manager on that project and I were on good terms when I left and he served as a recommendation for my next job. The situation wasn't nearly as exaggerated as you're making it.
Version control is a must have for any project involving more than a few files or a few developers. It's simply not acceptable to work without version control in this decade.
Yes, the approach was, in practice, wrong. Make the backup, get the patch out, then put in the deployment system on the side.
Yes this is the best approach IMO. CYA (cover your ass) by explaining the risks, take backups (file & db) and push the hotfix. Sometimes you have to work with what you got while moving toward an ideal.
You then sell them the version control benefits and get them to sign off on that scope instead of being an obstructionist.
Yes, this is good advice. I was a doe-eyed fresh dev back then and in an advantageous position in the sense that nothing was riding on this job. Getting fired wouldn't have been the worst thing in the world. That said, had I gone ahead and made a mistake doing cowboy development on a live site... it would've fallen in my head I would've lost the contract anyway.
As I mentioned in another comment, I work in health now. You really can't turn a blind eye to these things in my current field. You might say I found a field more calibrated to my speed-quality balance than the old job.
Many times it comes down to personal approach too. Believe me, I have zero patience for corporate environments and I'm not afraid to rock the boat because I've been fortunate to never have to care about losing a job. It's a great position to be in. I've just seen so many agencies and clients use cowboy programmers and not adhere to best practices that I've had to help them through that process and sell the best practices.
Glad you're doing well and def. w health you can't move fast and go cowboy because the stakes are higher. We have clients in the health space too and the speed kind of annoys me but I've gotten used to it. But we still have clients that have used bad devs and ftp code so I see the gamut.
Personally I like the in between. Not cowboy but not corporate.