Coding buddy - Interesting approach to Code Review

How often do you ask your peers to review your code? If not very often then here is an idea for you - find a coding buddy! The buddy system can be implemented in 2 simple steps. But firstly, here is the idea behind the buddy system:

Individuals can do great things, but two highly motivated peers can accomplish even more when they work together. Surely there's at least one programmer you work with who you admire or at least respect enough to adopt the buddy system with.

So step 1 is to find a person meeting the above criteria, he will be a second "half of an awesome part-time coding dynamic duo". It has been proven, that this approach really works - there are lots of well-known dynamic duos like:

• Batman and Robin
• Tango and Cash
• Mario and Luigi
• Starsky and Hutch
• Crockett and Tubbs
• Bert and Ernie
• Cheap and Dale
• Laurel and Hardy

Your duo can join this small hall of fame! ;)

Now it's time to move to step 2 - peer review. Let me start with clarifying what kind of peer review I'm thinking about. Peer review can have multiple variations. For sure, with you coding buddy you don't want to do very formal, systematic and rigorous reviews (inspection) you should be much more flexible and more into quick and informal meetings (peer deskcheck).


I think informal nature of peer deskcheck is the factor that makes is so effective. You can comfortably chat with your buddy and explain to him what is the business objective for given piece of code and what was your approach to the problem. It's a great way to make sure that your idea makes sense and you are on the right course.

Those are only direct benefits, indirect benefits include:

• improved team work - reviews help people to "accustom" to helping each other
• increased familiarity of code base - sharing knowledge is always important, reviews give developers a chance to teach others about their piece of code
• prevent individuals from going dark
• increased quality - "reviews motivate us to practice superior craftsmanship because we know our co-workers will closely examine our work. In this indirect way, peer reviews lead to higher quality."
  

And that would be it, try to implement those two relatively simple steps and check on your own if it improves your code, check if other people understand your design and learn from it.

What are the next steps? (assuming that it buddy system works)

• find more coding buddies as it means more ideas, more views which afterwards should lead to even better code and even better knowledge sharing
• learn about different types of peer reviews, other types can be also useful. (chapter 3 of Peer Reviews in Software: A Practical Guide)
  
• try to change your company's software engineering culture to include peer reviews as a part of the process which you follow, every one can benefit from it (chapter 2 of Peer Reviews in Software: A Practical Guide)

Finally, I couldn't stop myself from posting this cartoon:


Last words ...

• This post was inspired by Jeff Atwood's post "Who's your coding buddy". I know Jeff that you don't read such a obscure blogs like this one but thank you for your post!
• Quotations and images used in this post are from Jeff Atwood's post and from Karl Wiegers' Peer Reviews in Software: A Practical Guide
  

Mary Poppendieck -- The role of leadership in software development

Recently I keep finding lots of interesting stuff about team management. This time talk of Mary Poppendieck “The role of leadership In software development” came to my attention. I found it on Google's Tech Talks Channel. But what is it all about?

When you look around, there are a lot of leaders recommended for software development. We have the functional manager and the project manager, the scrum master and the black belt, the product owner and the customer-on-site, the technical leader and the architect, the product manager and the chief engineer.

Clearly that's too many leaders. So how many leaders should there be, what should they do, what shouldn't they do, and what skills do they need?

This will be a presentation and discussion of leadership roles in software development -- what works, what doesn't and why.

For me that introduction was interesting enough to spend 1 hour and 30 minutes watching the talk and after all I have to admit that it was absolutely worth it therefore I recommend you doing the same!




My main take-aways are:

• general overview how the concept of leadership was evolving staring from 1850 to present times. I was surprised how closely it was connected with army and how many important breakthroughs were triggered by wars.
• what really makes organisations work is not one standardized process and people that do exactly what is written down. In that model you can forget that people will be interested in process improvement, it's impossible to make a full use of people potential. Basically, it doesn't work!
• leader is a person with vision, leader's job is to communicated the vision, help the team members to understand it. Leader should act like a teacher, it's not his job to tell people what to do, his job is to tell people how things should work.

And finally, Mary was talking about three different kinds of leadership, here is a high level overview:

• Product leader -- it's a person which merges marketing knowledge (understands customers needs) and fairly high level technical expertise. Product leader should work closely with developers and is responsible for releases planing and making necessary tradeoffs.
• Functional leader -- this person should preserve knowledge and hold technical expertise leadership. Person like that should be responsible for solving the most difficult problems in all projects. Other important part of this role is to train people, help them getting better and grow to their full potential.
• Project leader -- funding, scheduling and tracking -- those are the main objectives for this role.

Those are the things which were particular interesting for me. Watch the talk and if you care to share then let me know what aspects were interesting for you.

The One Minute Manager ... don’t miss it!

Have you ever been trying to figure out how people work best with other people? When they produce good results and are happy about their job, company and other people? If you are one of those who feel that this is important and interesting then I can highly recommend you this book: The One Minute Manager. It's a very well-written book which you can finish in one evening. The main message is that:

People who feel good about themselves produce good results.

But in the same time it's important to keep the organisation productive. Authors are trying to show that those two objectives can be achieved in the same time, moreover, the best way to achieve good productivity is through people. It all can be accomplished by applying one minute management. To understand how it works you need to be familiar with three secrets of one minute management.

The First Secret: One Minute Goals

One Minute Goal Setting is absolutely essential, it introduces philosophy of 'no surprises'. The point here is to be clear about what has to be done from the beginning. Therefore:

The One Minute Manager feels that a goal, and its performance standard, should take no more than 250 words to express. He insists that anyone be able to read it within a minute. Manager always makes sure that people know what good performance is. Performance standards are clear.

Rationale for that:

You see, in most organizations when you ask people what they do and then ask their boss, all too often you get two different lists. In fact, in some organizations I've worked in, any relationship between what I thought my job responsibilities were and what my boss thought they were, was purely coincidental. And then I would get in trouble for not doing something I didn't even think was my job.

And this is how the process should looks like step by step:

1. Agree on your goals.
2. See what good behavior looks like.
3. Write out each of your goals on a single sheet of paper using less than 250 words.
4. Read and re-read each goal, which requires only a minute or so each time you do it.
5. Take a minute every once in a while out of your day to look at your performance, and
6. See whether or not your behavior matches your goal.

Why does it work?

When your goals are clear you can work until your job is done. All the time you can compare your results with your goal which gives instant feedback. And a few words about the feedback:

Clearly the number one motivator of people is feedback on results. In fact, we have a saying here that's worth noting: 'Feedback is the Breakfast of Champions.' Feedback keeps us going.

The Second Secret: One Minute Praisings

Manager should strive to help people succeed and become a big help to the organization, therefore manager's main concern, especially at the beginning of a new task or responsibility, should be:

Help people reach their full potential, catch them doing something right.

Managers usualy try to catch people doing something wrong ... so why "catch them doing something right"? To help people by letting them know in no uncertain terms when they are doing well, to praise them and make them feel good.

Remember you don't have to praise someone for very long for them to know you noticed and you care. It usually takes less than a minute. And that's why it's called a One Minute Praising

This is how the process should looks like step by step:

1. Tell people up front that you are going to let them know how they are doing.
2. Praise people immediately.
3. Tell people what they did right—be specific.
4. Tell people how good you feel about what they did right, and how it helps the organization and the other people who work there.
5. Stop for a moment of silence to let them "feel" how good you feel.
6. Encourage them to do more of the same.
7. Shake hands or touch people in a way that makes it clear that you support their success in the organization.

Why is it so important?

Key to training someone to do a new task is, in the beginning, to catch them doing something approximately right until they can eventually learn to do it exactly right.

but in some organisation it doesn't always work this way ...

That is what we often do with new, inexperienced people. We welcome them aboard, take them around to meet everybody, and then we leave them alone. Not only do we not catch them doing anything approximately right, but periodically we zap them just to keep them moving. This is the most popular leadership style of all. We call it the 'leave alone-zap' style. You leave a person alone, expecting good performance from them, and when you don't get it, you zap them.

The Third Secret: One Minute Reprimands

If you have been doing a job for some time and you know how to do it well, and you make a mistake, the One Minute Manager is quick to respond.

One minute reprimand has two parts and here is how it should looks like step by step:

1. Tell people beforehand that you are going to let them know how they are doing and in no uncertain terms.
   
   The first half of the reprimand:
2. Reprimand people immediately.
3. Tell people what they did wrong—be specific.
4. Tell people how you feel about what they did wrong—and in no uncertain terms.
5. Stop for a few seconds of uncomfortable silence to let them feel how you feel.
   
   The second half of the reprimand:
6. Shake hands, or touch them in a way that lets them know you are honestly on their side.
7. Remind them how much you value them.
8. Reaffirm that you think well of them but not of their performance in this situation.
9. Realize that when the reprimand is over, it's over.

The most important is to remember this:

You will be successful with the One Minute Reprimand when you really care about the welfare of the person you are reprimanding.

What might happen if you don't use this rule in everyday life?

If managers would only intervene early, they could deal with one behavior at a time and the person receiving the discipline would not be overwhelmed. They could hear the feedback. That's why I think performance review is an ongoing process, not something you do only once a year.

That's it, those are all the secrets of the one minute management in a nutshell. Maybe I can add one last thing:

"I can see now," the young man said, "where the power of your management style comes from—you care about people."
"Sometimes," the One Minute Manager said, "you have to care enough to be tough. And I am. I am very tough on the poor performance—but only on the performance. I am never tough on the person."

Sound easy and cool isn't it? In the end we spend lots of time working, if there is something we can do to enjoy this time then I believe we should at least give it a try. So if you are asking yourself: Should I apply one-minute management? The answer for me is obvious: YES!

If you found one minute management interesting I highly recommend reading the book. It will give you much more details, examples and guidelines how to become One Minute Manager.

Don't go dark!

Recently I found very interesting post of Jeff Atwood regarding developers and bad practice of going dark. It was so thought-provoking that I decided to write a few my opinions how it looks like within Cognifide. By going dark we should understand situation where developer is "locked in his room" for a long period of time implementing some piece of functionality until job is done. Definition of 'long period of time' will vary across different organisations. In our case, in ASP.NET team we try to manage granularity of tasks in way that new modules can be implemented in days. If implementation of some module is going to take 1 week then it's considered as a big task. So going dark for us would mean that some developer is "locked" for longer then 1 week working on some gigantic feature. What's wrong with that?

Actually dropping such code-bomb can potentially create many problems:

• if there was any bad design decision made then whole new feature can be rejected as it may not fit to main project design. Please note that while developer is in the dark working on his feature, main project keeps changing,
• it's hard for other team members to understand and maintain new code
• it's almost impossible to do code review

Fortunately for us, we use SCRUM to manage ongoing work. Daily meetings significantly reduce risk of going dark, so good for us! But is that enough to be happy about the process? Jeff pointed out two things:

"The brilliant developer must be capable of performing on a team,
making his work visible in modest increments and subjecting it to
scrutiny as it matures."

and

"Hiding your code until it's "done" may feel safer, but it isn't.
Sharing your ongoing code with your coworkers is scary, much less the
world -- but it also results in feedback and communication that will
improve your code and draw you closer to the project you're working on."

I would like to highlight this part: "feedback and communication will improve your code and draw you closer to the project".

Why is that important for me? From my perspective it doesn't matter so much if you are working on one huge project for a long time or on a few smaller, at some point you have your habits, your ways of dealing with tasks. After some time you have already solved most of the problems which means that implementing yet another class/module/feature will not give me much in terms of new skills, my code won't get better, in fact I'm quite sure that it will stay exactly the same.

Few ideas how to change it, how to encourage people to talk about code quality and good patterns and this way learn new things:

1. pair programing when implementing bigger features. Main point is to avoid situation when there is only one person working on the feature and in the end this is the only person which is capable of maintaining it. I'm not saying that people should all the time sit together and do proper XP, work in parallel as much as you can. Important is that working with someone enforces communication and design discussions which in the end prevent from going dark.
   
   
2. code reviews, that seems to be the most obvious way of improving my code, I need feedback from other people! Of course it would be great to see senior developers taking active part in code reviews, that would be the best way to share knowledge. But also it's worth to know what less experience people think, fresh approach is also important! :) As I see it, code reviews makes the most sense in the early stages of each project. But also it would be nice to have a 'code review' session once a month to point out some fresh ideas (people don't necessary need to show bad habits ... good practices should be also presented!). Important is to take notes, find consensus and write it down!
   
   
3. internal demo after each iteration, it's vital to keep everyone up-to-date, it's also important to reuse similar approach designing all modules. That is another chance to communicate with peers, to get others people opinion. And additionally, it makes much more sense for end user when delivered project works and acts as a coherently designed system.

In the end, one last point ... I believe that none of us would like to end up doing one-man projects all the time. It usually means very small progress or no progress at all. We have lots of smart and clever guys around, we have opportunities which people in one-man project don't have so let's make a use of it. Don't be anti-social, communicate and improve your code!