What do you do with a person like this?
-
"can't test"... 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, 2013I've got to go along with JSOP on this one. 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.
-
Background: 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?
Do you not have a team/group meeting where you discuss: 1) Massive Backlog 2) Continuous Improvements (where this would fall) 3) Code Reviews 4) Branches and the main branch stability? Without clarity of purpose and buy in, I assume it isn't happening. And as professional developers we spend 10% of our time doing continuous improvement. An analogy to painting is cleaning up when you are done. If I hire a painter, I expect him to leave a finished product free of masking tape, and if he used my brushes, they are cleaned, but if he used his, I think I still paid him to clean them... I am 100% okay if he does that on the jobsite as long as he cleans up before he leaves... So, we allocate it. Otherwise the code just starts cracking under it's own weight. With multiple developers we assign one person to be responsible to make breakthroughs (like parsing all the SQL and bind variables, getting that added to the build process, and either refactoring the code, or the "fixed when touched" approach and verified in code review).
-
Background: 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?
I had a similar problem. My solution was to not come back to the office and find another job instead. A better solution would of course be to first talk to him about the subject, the same way you did in this forum post. If this doesn't help, ask your boss to mediate, that's his job. If this doesn't help either... leave the company.
-
Background: 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?
Show him a benefit to being in a team. My current role is more implement and support, with a little business analysis. Moving into a team where others could answer the call was great. They were tech competent and even if I wrote the code using Hungarian notation, they could walk thru it. If a spec was there in full geek, they could translate. Each of us has our alignment and strengths, and are available to the others. As we don't dev, we do not do builds and tests. But communication tools of some kind. Does he have domain knowledge that is useful to all? Does he know (and share) the dark corners that need work? Lead, help, or go away.
-
"can't test"... 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, 2013You assume that there are infact hard copy "rules" to follow in the first place.. Chances are if there is even a "lone ranger" situation at all, there are merely arbitrary best practices and no actual rules being enforced. I can see both sides to this quandry. I am neck deep in being the "lone ranger" in a project (now 8 years). I have found the opposite problem. It was deemed accepted and almost preferred that it be only a resource suck for a single team member up until recently. So much time spent and with new leadership, I have been in the old "what is it you do here" chair. That has been disheartening. Now suddenly there a bunch of new "rules", expectations, documentation, support demands, and a whole "be a team player" narrative placed on me. Lots of productivity crushing "process", but still no Tonto. The one person army for the project may or may not have been of their own doing and is more a failure of project/product management and process. They may have gotten into some bad habits and now have become accustomed to being in their own sandbox. I sense of ownership maybe. To suddenly have to let others in to that sandbox, especially in a critical manner, can be perceived as hostile. But again, thats on management.
-
Background: 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?
I have worked with people like this over the years. They are dangerous and inefficient for teams of good developers. If he does not comply with your requirements, assimilate him...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
You assume that there are infact hard copy "rules" to follow in the first place.. Chances are if there is even a "lone ranger" situation at all, there are merely arbitrary best practices and no actual rules being enforced. I can see both sides to this quandry. I am neck deep in being the "lone ranger" in a project (now 8 years). I have found the opposite problem. It was deemed accepted and almost preferred that it be only a resource suck for a single team member up until recently. So much time spent and with new leadership, I have been in the old "what is it you do here" chair. That has been disheartening. Now suddenly there a bunch of new "rules", expectations, documentation, support demands, and a whole "be a team player" narrative placed on me. Lots of productivity crushing "process", but still no Tonto. The one person army for the project may or may not have been of their own doing and is more a failure of project/product management and process. They may have gotten into some bad habits and now have become accustomed to being in their own sandbox. I sense of ownership maybe. To suddenly have to let others in to that sandbox, especially in a critical manner, can be perceived as hostile. But again, thats on management.
I've been a "lone ranger" as well, and even then, I had rules. Since I was "just the programmer", I insisted that someone else look at the app in question before I submitted it for deployment. When I joined the my current team, they had rules in place, and if I want to work here, I have to follow those rules. If a given programmer isn't mature enough to adapt to changes to his environment, he can damn well go find another job, because "lone rangers" don't do anything but hurt the software and the company's reputation when crap slips into production due to a lack of testing. Beyond that, EVERYBODY works late when something breaks. I don't like working late. Or on weekends. Especially when it's not my fault.
".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 -
Show him a benefit to being in a team. My current role is more implement and support, with a little business analysis. Moving into a team where others could answer the call was great. They were tech competent and even if I wrote the code using Hungarian notation, they could walk thru it. If a spec was there in full geek, they could translate. Each of us has our alignment and strengths, and are available to the others. As we don't dev, we do not do builds and tests. But communication tools of some kind. Does he have domain knowledge that is useful to all? Does he know (and share) the dark corners that need work? Lead, help, or go away.
bryanren wrote:
Show him a benefit to being in a team.
That's generally called "getting a paycheck".
".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 -
clue bat - I like it.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
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.
Robust Services Core | Software Techniques for Lemmings | Articles
Good advice. 🙂 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.
-
Background: 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?
Ask yourself a question: why is he "unable to test code before pushing it"? Is he so stupid or is he so overworked (all these years without a help) and now has even less time to do what he is ordered to do (by manager) because he has to cope with endless questions and complains by you and others on top of his already busy schedule? And how about you - did you even try to see his situation or are you all under such stress that you do not even have the time to stop and think clearly? Did anybody actually asked him what he needs? ...or you just came in like a flood with "it is our code now and this is how it is gonna be .... you stupid little...." Start by writing tests and think how to divide the task in such a way that you do not need each others perfect and up-to-date code. Do you really need him to first implement/fix something for you to do your job or you could actually create some independent test-layer or fix it yourself but are lazy and complaining, all blaming the one and only that managed to keep it all running that long with bus factor of 1? Are you really helping?
