|
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?
|
|
|
|
|
a) Extremely.
b) About 30 seconds should suffice.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Just found out he fixed the error 8 days ago but, should I have to keep rebasing my branch over and over just to get a clean run?
|
|
|
|
|
Presumably you took the branch from the main sequence, not a copy of his "private working code"?
Someone needs to give him a lesson on only committing working code ... preferably with a cluebat.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Harsh but fair 
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
|
|
|
|
|
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
|
|
|
|
|
It depends if you want to be the next Lone Ranger. Remember, there can be only one.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Following the Dilbert principle[^] you need to promote him to the technical lead of the project. That will keep him happy at the same time as not losing the knowledge of the current solution.
|
|
|
|
|
I think you are just venting, which is fine.
Just don't let your venting turn into negative energy. If it does, that would not bode well for you, and people will start asking what to do with you.
Something to think about perhaps.
|
|
|
|
|
Urgh, too true this...
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" 
|
|
|
|
|
mainly venting, but still.
|
|
|
|
|
|
MarkTJohnson wrote: A small group of us have been moved onto the project ...
Presumably by a manager; he or she is the person that needs to resolve this issue. And Lone Rangers need to learn that the world will not stop turning if they fall under a bus.
|
|
|
|
|
"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, 2013
|
|
|
|
|
every single line of code we write, c#, sql, etc. is peer reviewed during a pull request and also gets tested in our QA environment.
Nothing ever gets deployed to Prod without being tested by our QA team first. If something makes it to Prod and is buggy, the QA team takes the hit first, then the dev.
#realJSOP wrote: I call bullshit.
|
|
|
|
|
I'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.
|
|
|
|
|
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
|
|
|
|
|
- escalate the problem to management & audit as a risk issue, ie $$$ - they understand that
- have management appoint a team leader who's word is absolute, implement DevOps - it's a whole team mindset, not a 'I' mindset - if he's not willing, point to the door, ta ta, you dont need him
- implement pair programming with the person, but, 1 writes code, the other writes the tests for it - have him start on the tests
- Implement the simplest DevOps you can start with - Jenkins is free, use Gauge or Gherkin/Cucumber etc, but start with something
if he resists, point towards the door. If management dont want you to do it, get a Consultant as the fall guy to implement DevOps
|
|
|
|
|
Write a one-page document on what you feel are the most important deficiencies of that code. (Not more than a page, otherwise, it is unlikely to be read).
Use third person as in "This code is doing things like this, preferably it should be like that", and so on.
Send it to your manager, with Lone Ranger in cc. Let not your manager say "Why did you not point this out earlier".
|
|
|
|
|
and what exactly does he do and what is this/his domain
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
MarkTJohnson wrote: He has long complained that he doesn't have the ability to test code before pushing it to develop
Do you mean production?
I ask because most of the answers seem to be interpreting what you are saying as pushing to production without testing.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
No, I mean the develop branch of git that I'm supposed to branch off of. Code compiled but when I ran it kaBoom.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
