Should I Stay or Should I Go?
July 1, 2008 9:58 AM Subscribe
What's the best approach to take with the a lead software developer after being left holding the ball?
About a month into a new full-time development gig (after almost a decade of contracting/freelance for me) the lead developer left for a two week vacation with assurances that we were more or less feature complete and the only thing left to do before launch would be cleaning up a few bugs.
Lies. (duh)
While on vacation we've found huge areas of functionality that were unimplemented, and others that were implemented so fragilely that they were bound to break. It's been a week of hell scrambling to get everything finished while at the same time not throwing lead-developer under the bus with the higher ups.
Lead developer has a huge amount of seniority. I'm the only other member of the team with any experience in the software industry (other developers have less than a year of professional experience). There's no formal project management at the company.
I'd like this job to work out. What approach do I take with the lead when he gets back? Do I point blank (in private) confront/talk-to him about the the lack of organization/management and what I view as a lackadaisical attitude towards developing code that actually works? Do I accept this is just his MO and work around it while covering my ass at the same time?
Any advice on ways to deal with this situation in a positive way would be appreciated. I'm used to being brought into situations like this as a contractor where I can drop in, hurt feelings, get something done, then move on to the next gig. I don't think that works in a situation you'd like to work out long term.
About a month into a new full-time development gig (after almost a decade of contracting/freelance for me) the lead developer left for a two week vacation with assurances that we were more or less feature complete and the only thing left to do before launch would be cleaning up a few bugs.
Lies. (duh)
While on vacation we've found huge areas of functionality that were unimplemented, and others that were implemented so fragilely that they were bound to break. It's been a week of hell scrambling to get everything finished while at the same time not throwing lead-developer under the bus with the higher ups.
Lead developer has a huge amount of seniority. I'm the only other member of the team with any experience in the software industry (other developers have less than a year of professional experience). There's no formal project management at the company.
I'd like this job to work out. What approach do I take with the lead when he gets back? Do I point blank (in private) confront/talk-to him about the the lack of organization/management and what I view as a lackadaisical attitude towards developing code that actually works? Do I accept this is just his MO and work around it while covering my ass at the same time?
Any advice on ways to deal with this situation in a positive way would be appreciated. I'm used to being brought into situations like this as a contractor where I can drop in, hurt feelings, get something done, then move on to the next gig. I don't think that works in a situation you'd like to work out long term.
It's entirely possible that the senior guy (on vacation) understands the product's requirement better than anyone else. He/She may even understand the product requirements better than the customer. Since you say there's no formal project management at the company I wonder how you know there is significant unimplemented functionality. If this person is returning in less than two weeks it's not clear to me what your sense of urgency is. When he/she gets back I would just ask him why some functionality has not been implemented - chances are the answer will be that it will be implemented in a subsequent release. It doesn't sound to me like you've been on the job long enough to know what's really going on.
posted by thomas144 at 10:23 AM on July 1, 2008
posted by thomas144 at 10:23 AM on July 1, 2008
You say "we" have found huge areas of unimplemented functionality. Who is "we"? I am guessing you mean the worker devs and testers, and base my advice on this assumption.
Start by documenting everything that you were told, and what you've found, and get the others who've seen this to be able to corroborate this without asking them to rat on the lead. E.g. - email one of the testers a fairly explicit description of an area lacking stability, and ask the tester to email back with any corrections to what you've said, and any comments. This creates a paper trail of support for you without you ever asking the tester to tell the higher ups what she has found, and without it making her look like she's ratting on the lead dev.
Once you've got some evidence to back you up, you're in a better position whatever comes next.
I would definitely NOT talk to the lead about "the lack of organization/management and what I view as a lackadaisical attitude." Toss an insult at him like that and you'll have to watch your back constantly. Instead, I'd suggest providing him with a summary report: for each area of functionality, state what the goal is, what the state of the project was at the beginning and end of the two-week period, and what remains to be done. You could bolster this by discussing the report with the devs and testers and getting them to sign off on the contents of the report before handing it to him. You can thus show what progress you've made (which IS your job) and not confront him about what errors he made (which is NOT your job) ... makes you look good without directly making him look bad.
Finally, read Debugging the Development Process. This will help you be the PM that your company (for whatever reason) has chosen to live without.
posted by Capri at 10:30 AM on July 1, 2008
Start by documenting everything that you were told, and what you've found, and get the others who've seen this to be able to corroborate this without asking them to rat on the lead. E.g. - email one of the testers a fairly explicit description of an area lacking stability, and ask the tester to email back with any corrections to what you've said, and any comments. This creates a paper trail of support for you without you ever asking the tester to tell the higher ups what she has found, and without it making her look like she's ratting on the lead dev.
Once you've got some evidence to back you up, you're in a better position whatever comes next.
I would definitely NOT talk to the lead about "the lack of organization/management and what I view as a lackadaisical attitude." Toss an insult at him like that and you'll have to watch your back constantly. Instead, I'd suggest providing him with a summary report: for each area of functionality, state what the goal is, what the state of the project was at the beginning and end of the two-week period, and what remains to be done. You could bolster this by discussing the report with the devs and testers and getting them to sign off on the contents of the report before handing it to him. You can thus show what progress you've made (which IS your job) and not confront him about what errors he made (which is NOT your job) ... makes you look good without directly making him look bad.
Finally, read Debugging the Development Process. This will help you be the PM that your company (for whatever reason) has chosen to live without.
posted by Capri at 10:30 AM on July 1, 2008
I would install Git and Jira, and by the time the lead dev comes back have the source code under control and the bugs and feature requests logged, prioritized, and assigned. To him.
posted by nicwolff at 10:46 AM on July 1, 2008
posted by nicwolff at 10:46 AM on July 1, 2008
Step one: document everything you implemented or fixed that was outside the scope of cleaning up a few bugs, and the person(s) who said that it needed to be done (including yourself, if you found something that, as you say, was fragile.)
Step two: separate that list into items that you felt needed to be done for stability, etc., items that came in from other people that count as reasonable and expected levels of bug fixing, and items that someone told you had to be done and you see as unexpected/unimplemented functionality.
Step three: when your boss returns, sit down with them and give them a status report on the bugs filed by other people that you fixed, and the issues you found and took the time to fix (with the emphasis on you believing they would improve stability or whatnot, and if your boss disagrees, they can always be rolled back.)
Step four: once step three is out of the way, let your boss know that you've also spent a significant amount of time implementing functionality that various people claimed should have been done. Show your boss the list, and explain the details of each request and how you took care of it.
As you do step four, remember: it's possible that your boss lied to you, but it is significantly more likely (esp. with no project management per se) that these other people took advantage of you, to get you to implement a shitpile of stuff that your boss had specifically rejected previously, or that they didn't realize they needed until the last minute and so your boss would have rejected previously. Or maybe your boss would have said yes, but complained a lot, who knows.
Odds are when you talk about this, your boss may get angry, and in part perhaps angry with you for doing the work instead of pushing back, but ride that out -- and respectfully point out that you understand the frustration, but that you didn't feel you were in a position to push back, and going forward you'd appreciate more guidance in that area. Meanwhile, take comfort that your boss is really mostly angry at the people making the requests having taken advantage of you, and of his absence.
In fact, your boss's biggest concern will likely be that they said "no" to some of these items, saying it was too late, but that you did those things anyway, and so now your boss will look lazy. That isn't your fault, your boss should have communicated more with you, but you're on the same side and I'm sure you'll come up with a strategy to prevent it going forward.
Of course, if your boss seems to believe that everything was normal while they were gone after talking to you, then either your boss way lying, or doesn't care -- something to take note of, so that you can plan accordingly.
posted by davejay at 2:06 PM on July 1, 2008
Step two: separate that list into items that you felt needed to be done for stability, etc., items that came in from other people that count as reasonable and expected levels of bug fixing, and items that someone told you had to be done and you see as unexpected/unimplemented functionality.
Step three: when your boss returns, sit down with them and give them a status report on the bugs filed by other people that you fixed, and the issues you found and took the time to fix (with the emphasis on you believing they would improve stability or whatnot, and if your boss disagrees, they can always be rolled back.)
Step four: once step three is out of the way, let your boss know that you've also spent a significant amount of time implementing functionality that various people claimed should have been done. Show your boss the list, and explain the details of each request and how you took care of it.
As you do step four, remember: it's possible that your boss lied to you, but it is significantly more likely (esp. with no project management per se) that these other people took advantage of you, to get you to implement a shitpile of stuff that your boss had specifically rejected previously, or that they didn't realize they needed until the last minute and so your boss would have rejected previously. Or maybe your boss would have said yes, but complained a lot, who knows.
Odds are when you talk about this, your boss may get angry, and in part perhaps angry with you for doing the work instead of pushing back, but ride that out -- and respectfully point out that you understand the frustration, but that you didn't feel you were in a position to push back, and going forward you'd appreciate more guidance in that area. Meanwhile, take comfort that your boss is really mostly angry at the people making the requests having taken advantage of you, and of his absence.
In fact, your boss's biggest concern will likely be that they said "no" to some of these items, saying it was too late, but that you did those things anyway, and so now your boss will look lazy. That isn't your fault, your boss should have communicated more with you, but you're on the same side and I'm sure you'll come up with a strategy to prevent it going forward.
Of course, if your boss seems to believe that everything was normal while they were gone after talking to you, then either your boss way lying, or doesn't care -- something to take note of, so that you can plan accordingly.
posted by davejay at 2:06 PM on July 1, 2008
« Older What documents should a Canadian bring along when... | Running Queries in MS Access for non-Access Users? Newer »
This thread is closed to new comments.
Think positive and only talk about things that are your business. Don't say or imply that the lead developer sucks, his attitude sucks, his code sucks, the management sucks, or the organization sucks since you've only been there for a month. However, it is fair game to say that staying up all night fixing bugs is not your idea of a good time, that process won't work for you long term, and that you need another solution.
So, first thing to do when you sit down with him is talk about your fantastic achievements in your week of heroics (this new functionality I implemented is great, look at all the bugs I fixed in a week, etc). He is your new boss, make sure you sell him on your accomplishments and your awesomeness. Do this regularly.
Once you've done that, you can say that you weren't completely satisfied with the development process. You can say something like "in the past, I have used XXX project management process with great success, I think it would really help avoid these last minute heroics, here are all the materials/a detailed description of the process, can we roll this out". You can also ask for a post mortem meeting to go over what went right, what went wrong, and what you can change in the future. If you are having issues with product quality, you can volunteer to write and roll out an automated test suite. Alternatively, meet separately with test, ask them how they could help improve quality, and then report those suggestions to your boss or encourage test to meet with them yourself.
Don't expect miracles here. This is the kind of problem that takes years to fix. Best you can do is to get an opening or some latitude so that you can create a development process that works for you. If you are not prepared to do almost all the legwork to implement your proposed solutions yourself, then you should probably STFU and suck it up until you get a better lay of the land. Good luck.
posted by crazycanuck at 10:20 AM on July 1, 2008