Looking for advice: project management / delegation...
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Good grief, that is a painful situation. I would jump all over the first consultant to come back telling me that they can't fix the bug, I would humiliate him in front of his colleagues by fixing the bug myself and then inform him I have changed his network id to loser. Alternatively, I would drop by their desk after a few days, sit down and shoot the breeze with them and find out what is going on.
Regards Ray "Je Suis Mort De Rire" Blogging @ Keratoconus Watch
-
I hear you it is a difficult. It is kind of strange to hear myself say this but have you ever used Scrum? I have been in a department using Scrum now about 8 months and it has some useful features. I like the daily standup and the sprints but the most useful thing so far has been knowing when something is going wrong early. Consultants may not be so eager about it but at least you know what is getting done every day. It has made a big difference for us but it took a bit to get everyone onboard but after they saw how it worked it was ok.
KevinMac wrote:
It has made a big difference for us but it took a bit to get everyone onboard but after they saw how it worked it was ok.
I'll look into this. Thanks!
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Shog9 wrote:
if i just assign them, they won't get done - i'll get vague status reports for a few weeks
Ask vague status reports for a few days. :laugh:
Shog9 wrote:
So i need some advice.
I cannot give why...
Shog9 wrote:
i'm absolutely terrible at communicating with other people even at the best of times
.
Shog9 wrote:
Any suggestions?
Chocolate cake. I did 3 just today. It's delicious!
Shog9 wrote:
Tricks?
How to Choose a Consultant[^] (Use at your count and risk :laugh:)
Shog9 wrote:
Fun games to take my mind off it?
Peggle Deluxe[^] Good luck!
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
Clickok wrote:
Chocolate cake. I did 3 just today. It's delicious!
;) Worth a shot...
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Good grief, that is a painful situation. I would jump all over the first consultant to come back telling me that they can't fix the bug, I would humiliate him in front of his colleagues by fixing the bug myself and then inform him I have changed his network id to loser. Alternatively, I would drop by their desk after a few days, sit down and shoot the breeze with them and find out what is going on.
Regards Ray "Je Suis Mort De Rire" Blogging @ Keratoconus Watch
Ray Kinsella wrote:
Alternatively, I would drop by their desk after a few days, sit down and shoot the breeze with them and find out what is going on.
Doesn't help much that there's something like a 12-hour difference between me and one of 'em. But, perhaps it's worth just scheduling daily 8PM status meetings... i've gotta try something different.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed.
If they are not good at what they do, why do you keep them around? Anyways you can always put them under pressure by meeting with them frequently and discussing the problem and the progress they made. Vague won’t help them in such cases. I am speaking with experience as I am a consultant and in similar cases I always hold meetings and discussions with the PM and with the team that end up putting a road map to the solution as well as a timeline
Shog9 wrote:
but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that.
Everyone understand Requirement, Design or technical Document.If that is not feasible than a simple email request :)
-
Shog9 wrote:
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed.
If they are not good at what they do, why do you keep them around? Anyways you can always put them under pressure by meeting with them frequently and discussing the problem and the progress they made. Vague won’t help them in such cases. I am speaking with experience as I am a consultant and in similar cases I always hold meetings and discussions with the PM and with the team that end up putting a road map to the solution as well as a timeline
Shog9 wrote:
but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that.
Everyone understand Requirement, Design or technical Document.If that is not feasible than a simple email request :)
Bassam Saoud wrote:
If they are not good at what they do, why do you keep them around?
The VP decided that we were doing this outsourcing thing. To Infosys. On the cheap. I've argued, but that doesn't go anywhere - i'm just the guy who gets shit done. So, time to make the best of it.
Bassam Saoud wrote:
I am speaking with experience as I am a consultant and in similar cases I always hold meetings and discussions with the PM and with the team that end up putting a road map to the solution as well as a timeline
Yeah, that's looking like something i'm gonna have to try. It grates on me, because... well, i'm used to tracking down problems that aren't properly documented, in rotten old code that isn't commented, sitting alone in a room for hours with a Sharpie and a ream of printouts if that's what it takes... it feels like i have to baby these guys. But perhaps that's just another conceit i have to work past. :sigh: :-O
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Break the task up just as you said you would do it yourself:
Shog9 wrote:
research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then fix assign the bug to someone.
Put deadlines on the parts and schedule status meetings to discus results at each milepost. You need to make it a practice to get more than just bug fixes out of this - get some usable regression tests as well.
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
they can't be completely worthless
Yes they can. What's their relationship to the project? Is it their only project? How do they get paid--by the hour, by the milestone? What's their skillset with relation to the project? How did you find them, and why are they interested in working with you, besides the money? What's the current contract with them say (or is it a verbal agreement)? Can their rate be docked if they deliver late? The reason I ask all these questions is, you basically need to figure out what their motivation is, and you need to figure out if they really are the right people for the project. What you describe in "I need to sit down and..." should actually be done by them as part of the verification that they did the job right. There's clearly a problem that doesn't lie entirely with your difficulty in communicating. Communication is a two way street. Ask yourself how these fellows are failing at communicating and if/how they are taking advantage of you. Anyways, if you can elobrate on the above questions/thoughts, I can see what other ideas I come up with. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Shog9 wrote:
they can't be completely worthless
Yes they can. What's their relationship to the project? Is it their only project? How do they get paid--by the hour, by the milestone? What's their skillset with relation to the project? How did you find them, and why are they interested in working with you, besides the money? What's the current contract with them say (or is it a verbal agreement)? Can their rate be docked if they deliver late? The reason I ask all these questions is, you basically need to figure out what their motivation is, and you need to figure out if they really are the right people for the project. What you describe in "I need to sit down and..." should actually be done by them as part of the verification that they did the job right. There's clearly a problem that doesn't lie entirely with your difficulty in communicating. Communication is a two way street. Ask yourself how these fellows are failing at communicating and if/how they are taking advantage of you. Anyways, if you can elobrate on the above questions/thoughts, I can see what other ideas I come up with. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
What's their relationship to the project?
Someone told our VP that foreign consultants were Teh Sh!t, so that's what we're getting to replace coders lost through attrition.
Marc Clifton wrote:
Is it their only project? How do they get paid--by the hour, by the milestone?
No. Hourly, i believe.
Marc Clifton wrote:
What's their skillset with relation to the project?
Based on my own observation, on a scale of 1-5 (with 5 being competent and 1 being the echo from a long piece of PVC):
- Basic (programming) language: 4
- Basic (English) language: 3
- Analysis: 3
- Verification: 3
- Documentation: 2
- Regression testing: 1
Or to put it another way: given a problem, they can find and implement working solution just over half the time, communicate that solution about 2/3rds of the time, and with a lot of luck and a little assistance, verify that it hasn't broken anything else about one time out of five.
Marc Clifton wrote:
What's the current contract with them say (or is it a verbal agreement)? Can their rate be docked if they deliver late?
I haven't been given much in the way of information here... From the look of things, the only people my opinion actually matters to have no power to change things (their contract is re-negotiated periodically based on how many warm bodies we think we need.)
Marc Clifton wrote:
Ask yourself how these fellows are failing at communicating and if/how they are taking advantage of you.
I already know the answers to those questions. I'm tilling a garden with a teaspoon. But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people. I appreciate all the advice i've been given here today... this is why i love CP - programming problems i can usually find a solution to, but stuff like this just throws me.
----
It appears that everybody is under the impression th
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. ... Any suggestions?
Yes. Get better "consultants". No, really. -- modified at 18:51 Sunday 8th April, 2007 I'll explain why I said that: what you're suggesting is (imho) the right approach to finding and fixing the bugs. But it's something you should be able to hand off to a capable developer. It appears that you're not in a position to enforce the "capable" aspect. Am I right? Or am I reading too much into your post? /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
Shog9 wrote:
i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. ... Any suggestions?
Yes. Get better "consultants". No, really. -- modified at 18:51 Sunday 8th April, 2007 I'll explain why I said that: what you're suggesting is (imho) the right approach to finding and fixing the bugs. But it's something you should be able to hand off to a capable developer. It appears that you're not in a position to enforce the "capable" aspect. Am I right? Or am I reading too much into your post? /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Hmm.... how about setting (or agreeing) dates for initial and full analysis then when you have that a date for the fix?
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Shog9 wrote:
i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. ... Any suggestions?
Yes. Get better "consultants". No, really. -- modified at 18:51 Sunday 8th April, 2007 I'll explain why I said that: what you're suggesting is (imho) the right approach to finding and fixing the bugs. But it's something you should be able to hand off to a capable developer. It appears that you're not in a position to enforce the "capable" aspect. Am I right? Or am I reading too much into your post? /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
The interesting point about Shogs question is: What if you can't get more capable developers?
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
Marc Clifton wrote:
What's their relationship to the project?
Someone told our VP that foreign consultants were Teh Sh!t, so that's what we're getting to replace coders lost through attrition.
Marc Clifton wrote:
Is it their only project? How do they get paid--by the hour, by the milestone?
No. Hourly, i believe.
Marc Clifton wrote:
What's their skillset with relation to the project?
Based on my own observation, on a scale of 1-5 (with 5 being competent and 1 being the echo from a long piece of PVC):
- Basic (programming) language: 4
- Basic (English) language: 3
- Analysis: 3
- Verification: 3
- Documentation: 2
- Regression testing: 1
Or to put it another way: given a problem, they can find and implement working solution just over half the time, communicate that solution about 2/3rds of the time, and with a lot of luck and a little assistance, verify that it hasn't broken anything else about one time out of five.
Marc Clifton wrote:
What's the current contract with them say (or is it a verbal agreement)? Can their rate be docked if they deliver late?
I haven't been given much in the way of information here... From the look of things, the only people my opinion actually matters to have no power to change things (their contract is re-negotiated periodically based on how many warm bodies we think we need.)
Marc Clifton wrote:
Ask yourself how these fellows are failing at communicating and if/how they are taking advantage of you.
I already know the answers to those questions. I'm tilling a garden with a teaspoon. But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people. I appreciate all the advice i've been given here today... this is why i love CP - programming problems i can usually find a solution to, but stuff like this just throws me.
----
It appears that everybody is under the impression th
Shog9 wrote:
but stuff like this just throws me.
Ah, it sounds like the small outsource team my client once hired. Mostly capable, as long as what they were doing was "by the book".
Shog9 wrote:
From the look of things, the only people my opinion actually matters to have no power to change things
Well then, this usually falls into the category of "the only person you can change is you." In other words, if your team doesn't take bugs and deadlines seriously, then you can't either--it's like tilting at windmills (or whatever the expression is).
Shog9 wrote:
But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people.
I've taken Dale Carnegie's "How to win friends and influence people" course, then was a teacher assistant for it, worked with people in person and half a world away, and no matter what you try, it comes down to chemistry and ethics. If there's no chemistry between two people, it creates imbalance. If a team member has no sense of ethics regarding the work, it creates imbalance. The only thing you can fall back on is a strong manager that gets rid of the people that aren't working out or motivates them with a big stick. Rarely, very rarely, is there a manager who can really inspire people and bring out the "ideal" in them. But as a "peer", I'm in the same boat, I've never figured out how to motivate coworkers. As a result, I just do what I can do, but I don't try to pick up the slack anymore. I used to, and the reaction from the slackers would be to slack even more, and I would get angry and frustrated and hate my job. Computers are much easier to work with than people. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
The interesting point about Shogs question is: What if you can't get more capable developers?
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistpeterchen wrote:
What if you can't get more capable developers?
If that's the case (as it might well be), he's probably going to be expending more effort in using the assigned developers vs. doing the work himself. The solution lies in someone higher up in the food chain being made aware and convinced of this. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
Bassam Saoud wrote:
If they are not good at what they do, why do you keep them around?
The VP decided that we were doing this outsourcing thing. To Infosys. On the cheap. I've argued, but that doesn't go anywhere - i'm just the guy who gets shit done. So, time to make the best of it.
Bassam Saoud wrote:
I am speaking with experience as I am a consultant and in similar cases I always hold meetings and discussions with the PM and with the team that end up putting a road map to the solution as well as a timeline
Yeah, that's looking like something i'm gonna have to try. It grates on me, because... well, i'm used to tracking down problems that aren't properly documented, in rotten old code that isn't commented, sitting alone in a room for hours with a Sharpie and a ream of printouts if that's what it takes... it feels like i have to baby these guys. But perhaps that's just another conceit i have to work past. :sigh: :-O
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
it feels like i have to baby these guys. But perhaps that's just another conceit i have to work past
The hardest part of managing people is to stop managing people. Give them tasks, tell them when you want it done, then get out of their way. If you constantly babysit people, people will act like babies. Treat them like adults. If they screw up, pin the tail on the donkey (but make sure you have documented your end to CYOA).
-
Shog9 wrote:
but stuff like this just throws me.
Ah, it sounds like the small outsource team my client once hired. Mostly capable, as long as what they were doing was "by the book".
Shog9 wrote:
From the look of things, the only people my opinion actually matters to have no power to change things
Well then, this usually falls into the category of "the only person you can change is you." In other words, if your team doesn't take bugs and deadlines seriously, then you can't either--it's like tilting at windmills (or whatever the expression is).
Shog9 wrote:
But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people.
I've taken Dale Carnegie's "How to win friends and influence people" course, then was a teacher assistant for it, worked with people in person and half a world away, and no matter what you try, it comes down to chemistry and ethics. If there's no chemistry between two people, it creates imbalance. If a team member has no sense of ethics regarding the work, it creates imbalance. The only thing you can fall back on is a strong manager that gets rid of the people that aren't working out or motivates them with a big stick. Rarely, very rarely, is there a manager who can really inspire people and bring out the "ideal" in them. But as a "peer", I'm in the same boat, I've never figured out how to motivate coworkers. As a result, I just do what I can do, but I don't try to pick up the slack anymore. I used to, and the reaction from the slackers would be to slack even more, and I would get angry and frustrated and hate my job. Computers are much easier to work with than people. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Computers are much easier to work with than people.
The next version release of people should come equipped with OFF switches.
-
peterchen wrote:
What if you can't get more capable developers?
If that's the case (as it might well be), he's probably going to be expending more effort in using the assigned developers vs. doing the work himself. The solution lies in someone higher up in the food chain being made aware and convinced of this. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
The solution lies in someone higher up in the food chain being made aware and convinced of this.
That may well be what this comes down to. Based on the advice i've gotten here, i plan to switch tactics: rather than trying to pass off bugs, i'll perform a very brief initial analysis, spec out milestones and estimate the time involved for each, and then track each: for every milestone missed or task that i have to end up doing myself, i'll log it as a contributing factor to delays on my own tasks (rather than putting in overtime to compensate). When the next release slips... well, one way or another, i guess i'll know where i stand.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
I'd love to know what Infosys is billing you for these guys....
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. Yeah, whatever....