RSS Feed

Latest Entries


First time here?


Wednesday
Sep092009

Step #4 - Start doing code reviews – Seriously

As one team lead to another, as someone who has actually done this with a real team, I can tell you that this is one of the few effective techniques to maintain a high quality bar in your code base, and to keep your people learning. It is also one of the beest ways to stay in touch with the codebase even though you are a team lead, and have much less time for real coding.

Whatever you do, don’t listen to others or even your own inner voice telling you that it’s a waste of time.

Code reviews are nothing short of a magical process of growing people, code quality and confidence at the same time, and it has changed the way we work at Typemock immensely.

What's a code review?

One developer looking at another developer's source code - thoroughly.

What do you look for in a code review?

  • Logical bugs
  • stupid bugs
  • Unreadable code
  • Ugly code that should be refactored

What is really the purpose of code reviews?

  • Besides catching bugs really early on, you mean?
  • Keep code at a much higher quality
  • share knowledge of new feature, requirements and code between people in the team (the reviewer learns about code they did not write)
  • Raise skill of both reviewer and review-ee ("oh I'll show you a much more elegant way than doing this ugly for-loop - see?", "That looks great - what do you call this pattern?")
  • Let the team know that you, the team lead, care - about them, about the code, about quality

Who should do the code review?

  • At first – Just you.

Everything has to start somewhere - and as a team lead, I expect you to know good code, and to recognize bad code (here's a good book about this subject or even better - a whole bunch)

  • Other team members (when you feel comfortable with it)

How and when should you do a code review?

There are two phases to this. The first one is the one where you bring the team up to par with what you consider quality code - You will be the only one doing code reviews - and no code is checked in before passing your code review. seriously. This is serious business and you should stand your ground. I cannot begin to tell you how much good this will do to the team - but you must stand your ground and give this a try.

  • Sit down with the team, or explain this at the end of the next daily standup -

From now on, every code being checked in has to pass a code review first.

That's right - every check in will be reviewed by you personally.

  • Wait for the next time someone is about to check in their code
  • Sit with the, and find the changed code. You can use the "show changes" tools from  the various source control tools (aka sourceSafe, SVN, VSTS etc.).
  • Go through each file and read the code. Do this even if the file checked in is not code – a text file, a solution file – it’s amazing how many gems you can find)

many times when reviewing you’ll find classes that are not in use anymore, or fully commented out, code that is duplicated and forgotten to be removed and many more “gems”.

  • Ask important questions about every little thing that bothers you:
    • "Why are those comments there?"
    • "Can we make this more readable?"
    • "This needs refactoring to smaller methods" and so on.
    • “How could you make this code more readable”
    • “What do you think is wrong with this piece of code"?”
    • “What would be a better name for this method?”

 

  • As you comment on the code have the developer put a special “REVIEW” or “REFACTOR” comment on that piece code which is easy to find later.
    • do not hesitate to say it if you feel that they are not paying attention or that they are not writing down those comments.
  • When you finish the review ask them to make any changes and show you the code again before checking it in.
  • Do a quick pass on the changes that were made (you can pass on this step after a couple of days if you feel comfortable enough)

Train the team to review its own code

I’ve said this previously, but I’ll mention this again:

Your most important role in the team is to act as a coach – to teach them to solve their own problems.

To that effect, it’s important that you not become the bottleneck for the team. The goal here is to make sure every checked in code is being reviews, without the team slowing down to wait for you every time. IN order to achieve that, have a third person sit with you and the review-ee (that’s 3 people on the same machine) and write down a list of what you are looking for in the code. That list will later be used to coach others on code reviews.

Have that third person change between reviews so everyone gets to learn.

The next step

When you’ve code code reviews for say- a week or two, it’s time to let the team start doing its own reviews. 

In the next standup meeting, declare that from now on, everyone can review each other’s code, with your supervision. From now on you will be the third person sitting behind two team members as they review each other’s code. As a team member reviews the code, sit quietly and only speak when they prepare to move on to a different file. If you have something to say, that’s when you can say it:

  • “What about naming conventions in this file? have you looked at those?”
  • “I’m still seeing something in this code that I think you missed – care to try and find it?”
  • “Why did you choose to apply this refactoring instead of X?”
  • “Why would you name it X?”

and so on.

typically, within a couple of days you should feel comfortable with them reviewing each other’s code, and free you up for other things.

 

What did we end up with?

When all is said and done , 2 or 3 weeks later, you should be able to say:

  • My team knows how to write better code today than they did last month
  • My team learned a new skill this month
  • My team can raise the quality but still be fully independent in doing so
  • I feel that I know exactly how out code looks
  • I know my team members better than I did last month

Those are things that you should be very proud to say. These are the hope of any team lead – that their coaching actually makes a difference.

You might still want to reviews code every now and again, and make sure the bar is still set to your standards. If it lowers again, you can repeat the exercise.

You should also have a better understanding of the strengths and weaknesses of each team member in regards to coding, sharing information, pairing and overall attention to detail. These will help you a lot when it comes time to grow people. I’ll touch on this in a future post.

Tuesday
Sep082009

How to find hidden problems in your project before it’s too late

A team lead I met a couple of years ago told me of a very effective technique he used in new projects and teams where he didn’t yet know what’s really going on, the team members, or all of the things that needed to be taken care of. He told me what happened the first time he tried it:

It was 5 months before the supposed release of the project he had just gotten into. everyone looked very busy but he didn’t really know where to start. So he gathered the team in one room, including one of the stakeholders (project lead) and the QA manager, and asked them all one simple question:

“Imagine it’s the end of the project – 5 months from now. We’re standing in this same room, and the project has totally and utterly failed.

Why did it fail?”

As he said that, people around the room started talking about various things that are currently holding the project down, risks that needed to be mitigated, and quality issues that needed to be resolved. The QA manager said he didn’t yet get anything to test, and that the way things looked he will get them waay too late, which means the release will surely be late. The developers said that they have been rewriting the software three times over so far since no one seems to really know what they want. One of the developers mentioned that they are only working on the project half time since they are also working on two other projects at the same time – so he didn’t see a way this ends well.

The team lead wrote down all those risks and after 45 minutes he had a ready made list of things that really needed taking care of.

He knew what he needed to do.

What can you learn from this?

If you are a new lead on an old project, there is no hard in trying out this technique. It is a smooth and brilliant way of getting people to think of obstacles, and fleshing out problems before they arose too late to take care of.

Gather your team, and take a couple of stakeholders with you (stakeholders are the people in your company that will suffer greatly if your team fails to deliver the project). ask them the question.

You might be surprised by what you find.

 

Do you have your own cool technique? Share it in the comments!

Monday
Sep072009

Making Impossible Decisions Without Panicking

Sometimes you're faced with a question that only has bad answers. A while ago one of my friends was faced with exactly one of those:

It turns out that the technology the team chose to use on the project was not scalable enough, 2 days before going into production.

They had several choices available:

  1. Host the non scalable part on a separate server and hope for the best
  2. Change the code behavior (requires lots of testing, in a rush, not a good idea!)
  3. find a different technical solution (impossible at that time frame)

All these solutions suck. but there is more you can do:

  • Consult with your whole team for other solutions. Explain them the situation and be open to hearing other solutions without taking them down.
  • Consider each solution for the time it takes, amount of people needed and the risk involved
  • Consider combining two or more solutions if it makes sense

Don't Panic

Whatever you do, especially if you're in a time rush - don't panic.

If you panic - chances are you will rush into a decision without thinking well about it, and might end up digging a bigger hole.

in this case going for option #1 and changing the code in parallel could be a better option than just choosing one of them.

I put out the fire - now what?

Now it's time to make sure you learn something from this horrible experience (and we've allbeen there) so that it does not recur.

Sit down with your team and try to gauge out the reasons why they think you came to this situation. For example

  • "We could have done something about this 2 months ago but didn't"
  • "We could have tested for scalability but didn't"
  • "We didn't really understand that the requirement was scalability of this magnitude"
  • "We wanted to do this early but never got to doing it due to lack of time"
  • "It was lower on our priority list"

etc..

Make sure it does not turn into a blame fest - no names. always make sure people use the term "we" since as a team you are all responsible for this. If people try to be negative and say they had nothing to do with this failure remind them that as a team everyone is equally responsible to anything that comes out.

After you're done making that list, sit down with the team and make a list of things that you commit to start doing starting today. It will be your job as a team lead to make sure the team has the time and permission to achieve these things.

Try to not be the only one saying something. Always be the third or fourth person contributing to the ideas, to show people that you expect them to be part of the process.

Here is what such a list can be:

  • "The team commit to doing performance testing of this application on a weekly basis"
  • "The team will always ask about scalability requirements for all applications from now on, and are they a must to go live"

It could just be one item, but one that you can really commit to - make sure you are not lying to yourself.

 

Sunday
Sep062009

Daily Standup Meetings - Introduction and 5 useful tips

 

A daily standup meeting is one of the easiest practices you can implement with your team. It only takes 10-15 minutes at the beginning of each day, and it increases the amount of communication and synchronization in the team immensely.

The idea is very simple

The whole team (usually no more than 10 people) literally stands up in a sort of circle so everyone can see each other. then the team lead (or the "facilitator" that was chosen for the team) will go one by one and ask each team member three simple questions:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. Is there anything stopping you from getting your work done?

Question #1 is important for several reasons:

  • Everyone hears what happened yesterday and know the current status on that part of the app that member worked on
  • The team lead understands the progress of  the team member and the overall status of the app
  • If the team member didn't get anything really done yesterday, it might mean they are stuck - which is very important to know early as we've seen.

Question #2 also has its uses:

  • The team member stands up in front of their own peers and says they will do something. They will feel more responsibility to make sure those things get accomplished. they are now accountable to the team.
  • If they do not know what to do today, that's also good since you've caught this early. make sure they know what to do. If there is a task board, they can grab the task with the highest priority, for example.
  • Other team members will know what is going on, can offer help or tips (maybe they worked on this just the other day?)

Question #3 is very important to prevent bottlenecks in the team productivity

  • maybe someone's computer is overheating, or has low memory
  • maybe a team member needs to take half a day since some other project called them
  • maybe... you get the idea

it is your job as a team lead to make sure nothing is stopping team members from working on the things with the highest value to the project(s) they are working on. If they are not, find out why and solve it immediately after the meeting.

 

5 useful tips I learned the hard way

  1. Make sure it does not take longer than 15 minutes (that's why standing up is important - people don't feel comfortable ranting on when they stand up so things finish up quickly)
  2. Make sure that technical discussions do not ensue in the middle of the meeting. when one breaks out call it out as a "talk about this later, just the both of you" and ask people to move on
  3. When all else fails, you can tell the person who won't stop talking - "you have  30 seconds to finish your overview" and then move on.
  4. Don't be afraid to stop people in the middle of speaking. The rules must be clear and concise.
  5. Once you have this meeting, try to see what meetings you can now cancelfor the whole team. For example, in our company we have only two meetings a week where the whole dev team needs to be in: daily standup, and once a week a company meeting. besides those they are just at work, working.
Sunday
Sep062009

4 ways to discover a stuck team member, and what you can do about it

More than five years ago I wrote on my .NET blog a little sad story about how I got fired from my job as a developer. You can read the full story here.

Here is my summary in the context of five or so years ago:

“As developers, we all make mistakes. It's the natural and human thing you can always count on. As a developer, it is your responsibility to make sure that at any given time, your team lead knows what you are facing and if you're having any problems. If you don't communicate this well using scheduled short meetings or even hall small talk, you're not giving your team lead a chance to help you. You're also setting yourself up to be the scapegoat if anything goes wrong since you are the only person that could have known and fixed any problems you are encountering.

As a team lead it is your responsibility to make sure that at any given time you know what every person on your team is working on ,if they are having any problems doing it and how long it is supposed to take. You should do at least a daily morning meeting with your team to review today's objective for each person, to leverage any problems anyone might have and to basically make sure that everyone is on the same page. Forget to do this basic thing and you're setting yourself up for big surprises down the line. Doing code reviews is also a great way to keep tabs on what's going and the quality of it. Harder to do, this should be done on weekly basis, or milestone basis (some even do it before any code check-in of any developer). forget to do this and you could wind up with code who's quality you are unsure of.”

Wow.

Re-reading this, I still like all the advice I’ve given. and these words were written with a lot of pain behind them, so this was a lesson that was really hard to learn.

I’ll reiterate the final situation that happened:

  • I ended up with a team lead who didn’t trust me, and actually went (almost) behind my back to solve a problem I’ve been working on for a long time.
  • I was afraid to go to work because I couldn’t face not accomplishing my work anymore
  • I was afraid to talk to my team lead
  • I was working hard and overtime
  • I was feeling lonely because I had too much ego to share anyone with my problems
  • My work was crappy. Never finished.
  • I was eventually fired.

What can I do to find this early?

As a team lead you can easily prevent such a severe case of mistrust and anxiety by following a few simple practices (which I will blog about in the days to come)

  • Have daily standup meetings
  • Do a code review
  • If you team writes tests, review them
  • Don’t be afraid to “ping” people or to pair with them on tasks

 

Daily standup meetings will find the problem of non-progress very early on. within a day or two any lack of progress will surface like a smelly apple in a bunch, but the point is that you found it early and you can take care of it. During standup meetings, when finding lack of progress for more than 1 or 2 days (you set the max limit but I don’t recommend any more than 2 days) – it’s a definite sign of “stuck”.

Code reviews are there to make sure the code quality passes your quality bar – you should only pass code you can stand behind.

Reviewing tests will reveal the intent behind the code people write and let you find problems with people’s understanding of requirements much faster than a regular code review.

“Pinging” people is alert you to any bottlenecks you can help solve during the work day.

The point of all these practices is that you are fully engaged with your team members, and gain their trust. By being there with them through think and thin, they will also feel better about telling about about things that aren’t working that great, since at the point you find them they are still really really small.

 

What should I do once I find a stuck team member?

Make sure a person will pair on that task with a peer or with you for at least one day, or hopefully until the end of the task. Pair programming actually works, but if you’re not ready for that yet, just make sure that stuck team member will have at least 8 hours of thought sharing and coding with someone else. it does a world of good to both of them.

Whatever you do do not let the situation continue. Team members are often silent but they expect you to help them, even without realizing it. It is your job to make sure that person is productive again. Pairing ont he task with someone else will unblock some brain waves, and creative thought can then resume.

What not to do

Don’t try to solve the problem yourself – at least, try to resist the urge. As a team lead, it is your job to empower the people in the team – to help them learn and get better. Solving their problems for them will not get them better, instead it will only get them more dependent on you. Instead, try to ask them for several possible options of how to continue from here, and then you can choose one, or let them choose one that you have no problem with. YOu can give them hints, clues, or you can leave them alone and just say “there is a solution – take X hours and find it with one of your peers”.

But this is a subject of a future blog post as well.