John Luif

I have been thinking about this lately and after reading Jim Newkirk’s and Brad Wilson's post on “How to make sense of Code Coverage metrics” I figured this is a great lead in.  Their post mentions looking at a trend which I completely agree with, setting hard and fast numbers never work.  While I like to see code coverage as high as possible and always shoot for that (I would love see 100%) there are times when this is just not reasonable.

So how does a team lead make sense of how much code coverage is good enough?  Well in my mind this is where code reviews come in.  There are the standard code reviews in which a class or two is looked at by the dev lead and/or architect then feedback is given.  I tend to lead toward a more active code review while pairing.  People do not even realize it but I’m doing a code review while I am sitting there.  Have you ever noticed how some people get defensive about their code in a code review and the people doing the review tend to talk down to the reviewee.  Well, reviewing while pairing tends to side step these issues and can be used as a great way to see what is being testing and what is not and why.

The bottom line for me is code coverage is a variable number backed by code reviews to make sure the highest percentage can be obtained.

This may be stating the obvious but I figured since I have not blogged in awhile why not.

Throughout the many projects I have been on and lead there is definitely a difference between a project manager and project leader.  Can they be the same person, sure but it takes a special kind of project manager to step up and be a leader.

Sitting back and letting the project go its own direction and gathering stats, looking at budget and resources are basic project management tasks.  This is what generally I see from a project manager.

What I expect from a leader is far more.  A leader guides the team in a direction.  This is not to say the team is not self organizing it just means that some guidance is given on the direction of the team.  A leader protects their team, when crap rolls downhill the project leader tries to spare the team from it as much as possible.  A leader is a problem solver not just a problem stater.  A leader builds a relationship with the team that is friendly but holds the right to lead the team in a direction that some may disagree with.  At the end of the day the leader is more accountable than the team which definitely puts more weight on their shoulders.

I’m sure many of you out there have worked with some great project leaders and you always remember who they are and hope that your next project will have some great leader that you will again remember.