Archive for November, 2008

Code Review

Monday, November 17th, 2008

All software engineers have heard of the studies that show how the cost of a defect increases by an order of magnitude for each successive phase.  If you haven’t heard of these it is now considered a maxim that if it cost $1 to fix a bug found in development it cost $10 to fix if found in QA and $100 to fix once it is in production.   This is one reason we consider processes such as unit tests and code reviews as critical to technology organizations.  Finding bugs earlier saves money in terms of the effort of the tech teams and no matter how large or small the business, getting the most out of the tech team is vital. 

The process that we’re focusing on in this post is code review.  The engineers reading this are probably groaning out loud and about to stop reading, but we implore you to read on.  Implementing a code review process in the correct manner can not only save the business money but also be a valuable tool for engineering cross training, mentoring, and professional development.  There are many different methods of implementing code reviews from group meetings to paired programming.  We have seen many various methods and while any method is better than no code review, the one that we’ve seen the most success as measured by engineering contentment, long term continuation, and defect identification, is the one-on-one peer review. 

One-on-one peer code review is conducted between two engineers who can interact in person, on the phone or via email.  The reviewer typically gets assigned a feature to review prior to the code being promoted to the testing branch.  This serves as one of the final steps in development prior to formal testing beginning.  The reason that this individual review is more effective in many ways can be attributed to the general nature of coding which typically involves periods of quite concentration alone.  There is no reason to expect that reviewing code is any different that writing it in the first place.  Secondly, engineers are much more receptive to feedback in private and reviewers are much more likely to ask tough questions via email with the developer as opposed to in a group setting with management present. 

A good resource for more details about the benefits of peer reviews is the book “Best kept Secrets of Peer Code Review” by Jason Cohen from Smart Bear, Inc.  Admittedly Smart Bear is selling software for peer code reviews but even with this bent the book is a good source of information about studies and the history of code reviews.  In one such study cited in the book that demonstrates why code reviews conducted in meetings are not as effective as code reviews done one-on-one,  they determined that engineers spent 25% of the time reading the code in prep for the meeting and 75% of the time in the code review meetings.  Interestingly, 80% of the defects were found during reading and only 20% discovered during the meetings. 

Whatever code review process you decide to implement, anything is better than not doing it as long as the team is bought into it as a performance and efficiency enhancer.  Consider providing some reading material on code reviews and let one or more of the engineers propose a code review process.  Engineers who own the solution are much more likely to be excited about it and follow through on it.

Team Size

Friday, November 7th, 2008

As you consider hiring plans for next year, one aspect of your organization that you should give some thought to is what is the optimal team size?  You may have heard of Amazon’s rule of “two pizzas”, which basically says a team should be no larger than what it takes to feed with two large pizzas.  If our experience in feeding engineers pizza is typical, this means about 8 to 10 people.  As a general rule, we think this is fine but we have some other factors that we recommend incorporating if you want a more precise number.  These factors include experience of the managers, how long the team has been together, and manager responsibilities.

Before we explore the factors that influence optimal team size, first we should discuss why team size is important.  Consider a team of two people, they know each other’s quirks, they always know what each other are working on, and they never forget to communicate with each other, sounds perfect right?  Well consider they also don’t have enough engineering effort to tackle big projects in a timely manner, they don’t have the flexibility to transfer to another team because each one probably knows stuff that no one else does and they probably have their own coding standards that are not common among other two person teams.  Obviously, small teams and large teams each have their pros and cons.  They key is to balance each to get the optimal result for your organization. 

The first factor that you should consider is the experience level of the managers.  If the managers are experienced they should be capable of handling more direct reports.  New managers should be given fewer direct reports in order for them to have time to develop their management skills.  Keeping resource maps up to date for 15 engineers can be overwhelming for a new manager but one that has done it for years would have no problem doing it.  If you are filling vacancies in your management ranks try to be as detailed in the organization chart as possible spelling out the manager positions that you are keeping for junior managers and those that your are expecting to hire a more senior manager.  If you have a team that will be assigned a very large project and therefore needs to be large in numbers, mark it down as requiring a more seasoned manager.

The next factor to consider is how long the team has been together.  A team of twelve people who have been together for eighteen months is likely to have entrenched processes that make management of them easier.  The team may already have mentoring relationships established or clear divisions of code for easier feature assignment.  A brand new team probably has none of these as well as no bonding and possibly personality conflicts that need to be worked through. 

The last factor that we consider key to determining the optimal team size is what management responsibilities are expected from the manager.  Do you expect managers to conduct a weekly half hour one-on-one meeting with every engineer?  Do your managers need to create and maintain resource maps for the engineers?  Do managers need to periodically assign themselves features to code?  All of these questions and more will influence how many direct reports they should have.  Obviously the more managerial or development tasks that you expect your managers to handle the fewer team members they should have.  If you have a Project Management Organization that helps managers handle assignments and statuses, the teams can be much larger. 

So the answer to how large the team should be is, it depends.  It depends on a variety of factors that we’ve outlined here.  As you start preparing your budget for next year, take a few minutes to consider these factors and ask your existing managers for feedback on how their team size has affected their ability to perform as a manager.