Sigh. This is how great developers see bad managers and avoid them.
1. Defect Rate: The more experience, quality developers are given the more complex tasks generally and actually generate a large amount of defects. Defects are also a case of amount of humanity involved in the area developed. More defects in HMI code because of more eyes. Defects are also based on testing, so if a code is rarely used or testing only cursory, defects are not found. This information can be found and highlighted in the FREE Debugging course from Andreas Zeller at udacity.com (Nope not shilling but found this course very informational).
2. Just because someone is an experienced developer does not mean they can estimate a job. One of the hardest things that developers are asked to do is SWAG a job. The numbers are generally way underestimated due to our human overestimation of time in future (look it up, I dont have the time. heh). These times get filtered back through contracts and customers and come back even less time. Exactly how many projects have you been on that actually made time/budget exactly as estimated? There is a reason developers work a lot of unpaid overtime.
3. Testing as you go along. Are you stating all developers should do Test Driven Development? Okay, then provide hard, frozen requirements up front. Oh wait, you are AGILE so that cant happen for larger items. Oh.. there we go.. inch pebbles.. I think the best estimate is down to 3-4 hour chunks of time. Okay, so I established that ETC is hard enough, now do it constantly in a changing requirements weekly. Wait, Im almost done here.. give me some time to finish... I thought I would be done before lunch.. but Im not done yet. Management responsibility is to manage the developer to help them and the management to make realistic time.. so "almost done" is not done.
- Is it Soup? That is what I heard from my bosses when I first started in the game. Is it Soup? 20 minutes from me being first assigned a task. No real concept of the entire task. You learn to answer "Shortly" and they stop asking. 2 weeks if they ask me now.. no matter what it is. They learned to give me real time to get a much better ETC out. One of my early ETC was "3 months" from spending 2 hours on the ETC. When given 3 days, the ETC was a year and it took... a year!
4. Development and constant need to have stuff explained. Verify they understand the first time. Language barriers exist constantly. Yes, this is a decent enough metric but if they can follow computer language logic, they are not dumb. I am at a place where it is expected for new developers to work 18-24 months before becomes productive. Still.. this is one that I can see if you want to cycle engineers to get better ones and do not have a large learning curve for your products.
5. This is general employee issue. Not specific to developers.
KLOC metrics and defect metrics are shown to have real faults when using them to judge a developer.
Things that managers (or leads, including myself) do that slow down/hurt development:
1. Not listen. Most of the time, as a lead, we know it all BUT we are NOT listening and not HEARING why some task will not come close to what we think will happen in the project.
2. Micro Manage. Start the task with a known stopping date and get buy in. Dont go every to them 4 times a day, put them in a fishbowl, look at your watch if they take a longer lunch or go to a doctor, and tell others you dont trust developers as they need to be lorded over (yes, had a manager do this). The developer will come to you when they realize they have issues or need help. You help them by resources, processes, talking, etc but If you then look at them like they are insane.. you will no longer have that trust and you will have way more "Surprises". Here is a metric: If a developer never needs help and has surprises on time and issues... if you are not micro managing them, this issue lies in the developer and they need help on personal time management skills at least. If you are micro managing, you should quit and find a new job.. you have destroyed your trust and your team will no longer be what it could be. They will hide from you, keep issues from you, and do less than they could because of your methods.
3. Stop going out on weekends when your Team is crunching for you. Your role as a manager is not just to give tasks, its to LEAD by example. If you want your team to push for a couple of weeks and you ask them to do so, YOU do it too. If you are stopping by on a Saturday to make sure they are working and you are not.. FIRE YOURSELF you are a micro manager and will crush your team. No one will want to follow you.
5. If you are really a hardass on defects, you generate an atmosphere of "I can't fail" which slows down development even more and products are not delivered. Look up "devopts". If a defect is found, we do not blame.. we know its human.. get the human out of it. Eventually, bugs are less and development is faster.
4. .. I can go on.. and on... but one thing that bugs me. How does the manager know more about the technical stuff than the developer? How does a LEAD, LEAD and inspire. "Be the Quarterback, not push the delivery quarter back."(c) - I am quoting me.
All of the above are designed to help you get a loyal team that will do things above and beyond to get a job done. It is in the best interest of a manager to get the loyalty and hard work due to it out of them. Then you can push them harder, and get more out of them. As one VP told me, we keep giving you 5 lb bag and 10lbs of crap and you guys deliver. Why? because we WANTED to work for the guy.