What do you do with a person like this?
-
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?
As a former "Lone Ranger" I found that source control was the issue when bringing in a wider team. We have been in the position where I would merge my changes back to the base line, he would get the latest version from the base and it would fail to even compile with hundreds of errors. If we then deleted his version and then copied directly from my source it worked perfectly. Be very sure where the problem lies before putting on the hob nail boots.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
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?
Its nonsense to say he cant test. Your project needs to create a test database to test against, and the Lone Ranger needs to be testing his new functionality against that. You could create a script to create an empty version of your live db and load test data into it. He needs to amend his connection string to test the app against that, or at the very least if its SQL paste his changes in SSMS (or whatever your RDBMS client tool is) and run it against the test db. In the long term you could aim to create a suite of automated unit tests which are run before a deployment to reduce risk further. If its government work, here in the UK we have to conform to certain standards part of which is having a test strategy and evidence testing has taken place (and not against live data). We are audited on compliance to this. If you have similar in your locale,you could be at risk of failing an audit and losing business.
-
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?
Having read the Habits of high performing teams post last week, maybe High Psychological Safety comes in here. Unclear of the organisation structure of this team, and maybe this will lean more toward a manager person to sort, but here goes: From their perspective they might be in a defensive position (dont have time to test) and they maybe worried that you lot will criticise how bad his code is. So, the first step is to have them understand that all of you are their to work. Yes your code is going to be different to what we might expect, but the reason we have been assigned to work with you is because what you have made so far is good for the company. You have done good, it needs to expand, yes somethings will change, but we are not here to murder you (i am a sarcastic person, remove the last part if this sarcasm doesn't work for you) Address all concerns as a team, do a meeting - I worry X will be Y. Others either agree or disagree, gets rid of the mental thoughts. Figure out what needs to be setup and what does not need for a team. Source control is always needed.
-
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?
If the management have basically ignored the project for "a couple of years now" then they have only themselves to blame, and should be thinking in terms of a recovery plan from their lack of support. It's not possible for a single person to be truly their own QA (etc), while still inside a big system (the management!). Someone needs to be the proper "support" person that helps the 'LR' victim identify and resolve the (administrative / management) technical debt, so as to back out those years of problems. Victim blaming, just because you / I / someone else would have had different problems, isn't a productive way out of this double blind. If the LR walks, will the project be cancelled, or will it be a death march? Is it better to 'promote' the LR to being lead advisor to relieve them from some of the historical hidden pressure? It's still a problem, in many ways, with your (company's) management. Did they know they'd let the project stall, why did the take on the new project without a review? It's not what's under the rock that's the problem, it's the rock on top!
-
Not using source control even when you are working on your own is asking for trouble. I still find it hard to believe that some devs don't use some kind of source control - heck back in 1991 when I cut my teeth coding as a COBOL programmer, we used source control.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
Golden standard is git, which is a bit hard to understand without previous experience of source control and a bit too intricate to use, especially from command line. Also it's hard to see the benefit of git versus the still rampant zip file + changelog + diff when working alone or in pairs. Palce 3+ people on a complex project and the time investment in learning git pays, especially if aided by a good client (which is NOT the command line*). * Command line git is powerful and it does make sense but it's a 10.000 levers and push buttons tools, awesome for a full time integrator but time consuming and error prone for a developer whose main competences are code, design, architecture of the product. If it was not for a particular git client, I would never have been sold on git itself. SourceTree is free and has a terrific log analyzer but the UI to manage the repository sucks, the tool I use (not mentioning because it's free only for personal use) has a less than optimal log analyzer but a perfect UI to manage the repository.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
"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?
