Last time I interviewed someone, I did an hour of pair programming with the candidates. I selected something from my regular work that was small enough to take a bite out, and easy enough to explain in little time. So I actually got work done during the interview:D
It was an experiment, but it worked extremely well. At first the candidate is nervous, especially since (s)he is not likely to have experience in pair programming. But soon (s)he settles down and starts to get into it.
The one I ended up hiring was the one that I had to force to stop after one hour. He still wanted to make a little adjustment here, add some functionality there. Easy to tell he was very passionate about his work.
There is no way you can fake the thought process when you have to develop software it in real time. I can recommend this approach to anyone.
So, to anwser the question: you could offer to pair program with one of their developers.
Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices?
You don't need to lobby for best practices. How could anyone be against that? Just do it. Make no noise about it, don't expect awards or anything, just go about it.
As always, start small. Introduce best practices one by one. And don't go overboard. Unit tests are good, but you shouldn't spend the next three months doing nothing but writing tests. After all, you get paid to provide business value.
And remember that sometimes little things can have big impacts. Static code analyzers can sometimes find bugs for you without you even having to write a unit test. A unit test that catches a bug introduced by a co-worker may get his interest in unit testing. And if the little things you do have only little impact, well, that's fine too. After all, you're in for the long run, aren't you? You're running a marathon, not a sprint.
Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?
Yes, and no. Mostly the customers are right. After all, they are the ones using the software, not you. But I work on shrink wrapped software and sometimes what one customer wants is just not what most other customers would want. In those cases, you need the luck that the one calling the shots notices this too and isn't blinded by $. In the former case, you're blessed. In the latter, well, you probably have more than one problem...
Slashdot Mirror
It was an experiment, but it worked extremely well. At first the candidate is nervous, especially since (s)he is not likely to have experience in pair programming. But soon (s)he settles down and starts to get into it.
The one I ended up hiring was the one that I had to force to stop after one hour. He still wanted to make a little adjustment here, add some functionality there. Easy to tell he was very passionate about his work.
There is no way you can fake the thought process when you have to develop software it in real time. I can recommend this approach to anyone.
So, to anwser the question: you could offer to pair program with one of their developers.
As always, start small. Introduce best practices one by one. And don't go overboard. Unit tests are good, but you shouldn't spend the next three months doing nothing but writing tests. After all, you get paid to provide business value.
And remember that sometimes little things can have big impacts. Static code analyzers can sometimes find bugs for you without you even having to write a unit test. A unit test that catches a bug introduced by a co-worker may get his interest in unit testing. And if the little things you do have only little impact, well, that's fine too. After all, you're in for the long run, aren't you? You're running a marathon, not a sprint.
Yes, and no. Mostly the customers are right. After all, they are the ones using the software, not you. But I work on shrink wrapped software and sometimes what one customer wants is just not what most other customers would want. In those cases, you need the luck that the one calling the shots notices this too and isn't blinded by $. In the former case, you're blessed. In the latter, well, you probably have more than one problem...