|
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.
|
|
|
|
|
That's could also be because he forgot to add some files to the branch - the usual indication of this is it runs fine on his local machine but when you switch to the branch you hit issues.
If he can run everything fine when switched to that branch, the chances are he has forgotten to commit some file(s) to the branch.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
True, but so far it has been screwed up SQL command strings.
|
|
|
|
|
Tactful for a month, hard later.
I've been The Lone Ranger Under Pressure (out of necessity) more than once and I didn't acquire the capabilities of working in team, also to provide clean releases - after all nobody will test it or maintain it therefore I could build now and fix twhen.
I was also cajoled in working with a Lone Ranger Because Probably Autistic who did not comment, design, document nor used any form of source control. Since he was the Depositary of All the Knowledge and was also the Holy Cow of the customer company, I lost, in three months straight I resigned. Granted, I did not resign because of him but his crappy way of working made what was a daunting proposition simply impossible.
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
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
