How can I cover my back when programming? (Building redundancies and not leaving things to chance)

Question

I work in a very hostile environment/company (which I am a junior dev in), and of course, if you do some coding, it goes live, and there is an error, your job is on the line.

In this company (and all others I have worked in), I have never had any dedicated testing tools available. We have no source control, test servers, bug tracking, etc., yet we have completed large scale development for clients.

How can I ensure that my code, however small, will work in all environments? I already don't leave anything to chance and try to build in redundancies and backup plans. Eg if for whatever reason I decide to log errors by email, I know this means I am putting all my eggs in the basket of "the internet must be live" and it could easily not be, and if so, no logging will happen and if someone says there was an error, I have no proof and "his word against mine" doesn't work for me as I am junior. So everything has to be logged, which incurs a performance and storage penalty of course.

What techniques can I apply to ensure my code will work in different environments? This doesn't apply to browser compatibility, just with things like winform apps and making sure I can write to the event log on every machine.

I am doing the backup/redundancy idea (eg if I can't log to mail, log to local file), as well as logging everything, and not hard coding system values which vary from machine to machine.

At home I have things like unit testing tools, Exception Hunter, all sorts of stuff, to help me. At work I don't.

I am interested in C# techniques to help with this (the language I use at work and generally my primary skill) and general programming techniques. I haven't found much on this on Google.

Also, is it a bad technique if I log to email and in my catch method, if that fails, I log to file? (so I have a plan if one method doesn't work). It seems I should make the performance/technical sacrifice to cover my back.

Thanks

Answer 1

This sounds like a nightmare. I've worked at places where there was no source control, people made changes on the fly to live systems, and where I've had to definitively prove that my code wasn't the problem. But our jobs weren't on the line if someone screwed something up. Just so long as it didn't happen too often.

That's probably because one of the senior developers was the worst offenders. His favorite trick was to have shell scripts calling shell scripts calling shell scripts and explicitly redirecting stdout and stderr to /dev/null, sometimes 2 and 3 layers deep.

Then there was the time he "verified a customer's backup" at their request by making sure the job was running from cron rather than actually reading data from the tape. Of course the tape was bad - and he'd redirected stderr to /dev/null. When the customer lost a hard drive and 5 years of historical data 2 months later, I got to lead the effort of scanning in and OCRing their printed records to rebuild something resembling a database. They promoted the other guy. I quit not long after.

Which brings me back to your situation.

• Have your resume up-to-date.
• Have some savings in the bank; be able to look for a job without being homeless after 2 weeks.
• Start quietly looking for other work. This economy won't last forever, and you're getting more marketable every month. Life is too short to put up with a hostile workplace.
• Do what you can to CYA.
  • Start using an RCS for your own stuff.
  • Test your stuff thouroughly. Keep the tests around; re-test when you make changes.
  • Keep notes (email it to yourself, or edit a text file) about what you've changed, and how you've tested before deployment. With some luck, good documentation will trump a more senor guy's finger-pointing.
  • Look for a mentor within the company.

Good luck. As another commenter put it: we've all been there.

Answer 2

Set up source control for yourself, if nothing else.

If it were me, I'd go further: I'd install Trac & Subversion on my dev machine, and use it. If others start to wonder how I managed to track down the exact change that introduced a bug, etc, I'd point them at the URL. Let it grow virally.

But it sounds like you need to find a better place to work.

(Disclosure: I'm one of the Trac devs, so I'm biased.)

Answer 3

I work in a very hostile environment/company (which I am a junior dev in), and of course, if you do some coding, it goes live, and there is an error, you're job is on the line.

Been there, done that. How many people have you seen actually fired because they had a bug in their code?

In this company (and all others I have worked in), I have never had any dedicated testing tools available. We have no source control, test servers, bug tracking, etc

Therein lies the problem.

What techniques can I apply to ensure my code will work in different environments?

You can't. You can have a bank of machines (or virtual images) with various configurations to check against. But it doesn't sound like your work environment is conducive to that. If you just want logging capability, that should be a given.

I am interested in C# techniques to help with this (the language I use at work and generally my primary skill) and general programming techniques.

While I admire your dedication, that's like making a doctor build their own stethoscope, when it's much more cost-effective and safer to buy one.

Unfortunately, your organization will probably not make the changes they need to do it correctly, and you can't do it all yourself. Pay your dues there for a few years, learn all of the right tools, and then find a better place to work.