The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
Or don't take the medication at all, and become the bartender at James Bonds favorite pub.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
I have a colleague who has been the Lone Ranger in a project for a couple of years now but recently that project's problems has become a much higher priority (it's a system for the gov't and we've landed a significant new contract to expand this service to a larger number of gov't agencies, ergo the higher visibility).
A small group of us have been moved onto the project to help get everything up to snuff. He has long complained that he doesn't have the ability to test code before pushing it to develop, which is partially true.
However, there is some basic testing he COULD do but apparently doesn't since I can't get my code tested for finding bugs in stuff he's pushed to develop. Things like testing the SQL to make sure it doesn't throw syntax errors or "Inconsistent types" (comparing a boolean to a string)
Since he's been the Lone Ranger in this code for so long, he's a little prickly about us coming into his domain.
How tactful should I be and how long should I remain tactful?
You said that it's partially true that he can't test his code before submitting it. For some reason, this wasn't a big deal before, but now it is because the project is higher profile with more people working on it, probably with harder deadlines.
If I understand the situation correctly, he needs to be available to help downstream developers debug his code when it doesn't work. The tricky part is that those developers can't interrupt him until they're reasonably sure that the problem lies with his code. It's no fun to be interrupted for this kind of thing, so it will encourage him to test his code to whatever extent possible.
In parallel with this, it sounds like you need automated tests that he can run, and that the downstream developers will have to create those tests. I assume this because, otherwise, he could presumably run those tests himself, whether automated or not.
This is not a question of tact but should be seen as a reasonable way to speed up development.
I second the idea that new developers should help with dedicating some of their time to implementing unit tests. Regardless of how difficult the testing circumstances are, that should still be a realistic option.
You point out problems with something, and you are "the negative guy" all of a sudden. People are just lazy and can't be bothered to deal with problems, they prefer to just pretend they don't exist until the have to. I guess the term is "reactive management"
I call bullshit. He can write an app that can exercise ANY stored proc in a sql server database. I know, because I've done it. There is absolutely NO EXCUSE for pushing (SQL) code out to production that hasn't be tested. NONE.
Point of fact - using SSMS to write stored procs (or even just queries) is absolutely the best way to flesh out problems. SSMS won't even let you create a stored proc that isn't at least syntactically correct.
We have several dozen scripts that we use to run complex stored procs with a fixed set of params, and we know exactly what we want in the result set.
If your "lone ranger" programmer doesn't is more interested in his own agenda than actually being part of a team, the best way to handle it is to fire him. Right now. The sooner he's not a problem, the better things will get for the rest oft he team.
I work with eight devs and four DBAs (also in a DoD environment), and EVERYBODY follows the rules regarding testing before deployment.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
I've seen far too often where software gets thrown onto production when it could not possibly have been executed, and then it's a huge shitstorm to try to get the bug fixed. Of course, that normally involves hacking something together.
There might be times when testing is missed (i.e., didn't think of case X), but to say "I'll test by putting something into production" is grounds for immediate termination.
Well, I wish it was. But I work with morons.
Last Visit: 3-Dec-20 8:01 Last Update: 3-Dec-20 8:01