I am often asked what my opinion of doing code reviews is.  My answer might surprise you.

I don’t like them.  I prefer not to do them.

What?

Let me be more specific.  I don’t like code reviews that happen after the work is already done.

I do like code reviews that happen continuously as the work is being done.  This is called paired programming.  (This prezi presentation might also be helpful.)

Paired programming = continuous code review?

Yes.  That is exactly what I am saying.

Think about it for a second.  Can you really have a better, more honest and more interactive code review than paired programming provides?  If two developers are working jointly on a portion of code, it is being reviewed as it is being written.

I’m going to divert a bit to talk about some of the common problems that happen in code reviews, then I’m going to talk about how paired programming solves them.

Code review problems

#1.  Not telling the truth

There really is no value in a code review where no one says what they really think is wrong with the code, and instead picks out some little non-offensive thing like a naming convention that wasn’t followed.

All too often, code reviews are dominated by a fear of insulting the person’s code that is being reviewed.  This kind of weak code review provides no benefit.  I would go so far as to say it is reinforcing the practice of writing bad code, because bad code is rubber stamped.

#2.  Ego

To have a successful code review everyone has to check their ego at the door.  This rarely happens.  Code is something that has been creatively designed, not too many people can take a critique of their labor, even fewer of their art.

Without a spirit of humility and openness, code reviews don’t provide any value.  It is one thing to point out a problem, it is another thing to do something about it.

#3.  Wrong focus

One of the most common errors of code reviews is paying attention to formatting, coding style, or naming conventions.  Those topics don’t belong in a code review at all.

Tools can automatically format the code and statically analyze problems with coding style or naming conventions.  It is a complete and total waste of time to have a human reviewer review any of those things.

Seriously, if someone comes into a code review and they haven’t run the auto code formatter on their code, and they haven’t run the static analysis tools and fixed the problems found there, don’t be rude, just tell them nicely that their code is not ready for review.

Side note here: There is often debate on whether we should enforce code formatting,or enforce coding style, or enforce naming conventions.  YES! YES! YES!  Consistency is hugely important!  Code is read more than written, and consistent code is easier to read.  Have this discussion once, put together the automated tools to automatically format the code and automatically check the requirements.

Don’t spend months making up your special coding standards document.  Use some rule sets from any number of static analysis tools and start enforcing them.  Make them part of your build, make check-ins fail for formatting problems, make your IDE auto-format on save.  Deciding the perfect placement of curly brackets and whitespace is not nearly as important as being consistent.  Just pick something and enforce it.

Code reviews should focus on design, structure, and understandability of the code.  Code reviews should never ever ever ever ever ever ever focus on anything that can be automatically checked or enforced… ever!

#4.  Rush & Inconsistency

Teams rarely have or make time for code reviews.  If they do, it is inconsistent and not applied to all code, which causes the value to be lost.  If you have a huge fence around a perimeter, yet a large hole where people can just crawl in, the fence is worthless.

There is no point doing a code review where the code is not reviewed in depth.  Just scanning over the code and picking on a few variable names here and there does no good.  If you’re not prepared to fully immerse yourself into the code being reviewed, and dive deep down into understanding exactly what it is doing, don’t bother.

Paired programming to the rescue

Paired programming is like just-in-time code reviews.  It solves many of these issues by having a common goal and creating a joint ownership in the code.

As you pair up with different members of your team, you are likely to be more honest, be less egotistical, focus on the problem not the conventions, and delve deeply into the code.

It is no secret that my preferred modus operandi is no code review, instead paired programming, with everyone monitoring commits to source control, and can flag something and have a discussion if they see something troubling.

What if paired programming is not an option?

Well, try to make it one.  Paired programming is a great investment.

But, if you are not doing paired programming, you absolutely should be doing code reviews. I might have extolled some of the problem with code reviews, and I advocate paired programming, but let’s not mince words here.

Pair programming is a better way of doing continuous or just-in-time code reviews.  Not doing any form of code reviews is just plain stupid.

If you had a construction team building your house, or your 20 million dollar sky scraper, and they told you that they were not doing engineering reviews of the work that was done, you would probably fire that construction company on the spot.  Building software is several levels of complexity higher than that of most physical construction projects.  If you call yourself an engineer and you are not subjecting your work to regular review, you are just an amateur playing “engineer”.

So, if you must do the old-fashioned code review, here are some tips I found useful:

• Encourage people to be honest by doing some exercises where everyone reviews some code that wasn’t written by anyone on your team.  Encourage people to be as prejudice as possible when reviewing the code.
• Set your expectations.  Code reviews are not an approval process, they are an improvement process.  Make sure the team is aware of this.  Code reviews are a place you take your code to make it better, and to better your skills.  Foster that kind of thinking.
• Automate all of the nit-picky stuff and set coding standards, formatting standards, and style standards.  Decide what they will be together, or have your experienced people do it, but get it done, make conformance non-optional and make it automated.
• Develop consistent standards and practice about doing code reviews.  Set aside enough time to delve deeply into the code.  Set and enforce standards of when and how code is reviewed.
• Lead by example.  Proactively ask members of your team to look at your code and tell you how to improve it.  Ask if this can be done a better way.  Show a genuine interest in feedback and improvement, this attitude will catch on.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

For this post I want to clearly define what I am calling “Kanbanand” with two primary goals in mind.

1. Allow someone who is interested in doing a Kanban like process to find enough information to be successful.
2. Create a common thread for people who are already basically doing what I am suggesting.

Three Pronged Fork

I want to present Kanbanand as a three pronged fork.  In my mind there are 3 distinct areas of a successful Agile process which must be addressed.

• Business and overall encompassing project process.
• Development practices, including standards and best practices.
• Infrastructure: build systems, deployment, source control.

We must know how to run our day to day process, how we physically construct our product, and how we actually build and deliver the product.

Process

Rules:

1. Project is broken into stories which are small vertical slices through the system which are prioritized.
2. A Kanban board is used to make the progress of a team visible and has limits to control the Work In Progress (WIP).
3. At least once a day team members meet around the Kanban board in a stand up meeting to talk about the progress of the board.
4. The team meets on a regular basis to have a retrospective to discuss how to better improve their process.
5. Teams always pull in work, work is never “pushed” in.
6. Once work has been approved as “done” it can never be “not done”.
7. Find something to measure and measure it.
8. The team is responsible for, and empowered to determine how the team accomplishes its goals.

Values:

• Roughly same sized stories over irregular sized stories.
• Stories specifying what, over stories specifying how.
• Stories that are one sentence over stories that are one page.
• Talking about how to move the board forward over talking about what I did or someone else did.
• Cross functional teams over specialized teams.

Development

Rules:

1. All code is unit tested.
2. Static code analysis tools are used to set code standards, all code must meet those standards.
3. Any code that is done, is completely done.  It is refactored, it is unit tested, it meets the quality standards.
4. Code is never commented out.  Anyone is allowed to delete any commented out code at any time.
5. Determining code is meeting the quality standards must be done in an automated way.
6. No one owns code, anyone can work on any code.
7. Documentation is ONLY created when it will serve a known purpose and has an immediate value.  (Code should document itself with good names and simple flow, unit tests document the low level requirements of the system.  Automated tests document the behavior of the system.)
8. Testing requirements come from the customer, not from the developer.

Values:

• Test driven development over writing unit tests after the code is done.
• Pair programming over working alone.
• Readable code over smaller sized code.
• Doing things right over doing things fast.
• Showing the customer over asking the customer.
• Impromptu discussions at white-boards over scheduled meetings.
• Building tools that will help make completing ten things faster, than completing one thing faster.
• Writing automated tests over manual testing

Infrastructure

Rules:

1. Code is continuously built and integrated as soon as it is checked in.
2. Builds build code, run unit tests, run quality checks, produce deployable bits.
3. Builds fail if any unit test fails, or any quality check fails.
4. Code is only deployed from the exact bits that were produced by the build machine.
5. Code can be deployed to any environment with the push of a button.
6. Production data never goes to any other environment.
7. Developers can always run a local build which is the same as what will be built on the build server.

Values:

• Moving forward to fix problems over rolling back.
• Integrating soon over merging later.
• Quick builds over slow builds.
• Deploying on demand over deploying on a schedule.

Feedback?

That is my first crack at it.  I have tried to keep the process as simple as possible, but still include as rules the things that I think are most important to be successful.  I tried to keep the things that involved judgment calls as values.  I believe this provides enough information to allow an organization to create a custom process that will work for them, but will still have enough controls to be consistent in the things that I feel make Agile practices valuable.

Let me know what you think, or if you have any suggestions.  I will update this post as this list evolves.  I am sure there is something I missed or could state in a better way.

Like I said before, if you are doing some form of Kanban, you probably are already doing Kanbanand.  If you are doing Scrum, your major change would be to drop the planning and instead try to get same sized stories while limiting your WIP.

There were some really good sessions and good discussions on Agile, Scrum and domain specific languages.

I think events like these are important because they help us to zoom out a little and see what kinds of things other people are doing in our field and what companies around us are interested in high quality software.

Code camps are also a great place to get some experience doing presentations and share what you are working on.  Networking opportunities abound.

I presented two talks this weekend.  I am posting the links to those here.

The first presentation I did was on Pair Programming.

You can find the presentation on Prezi here.

We also did a live pair programming session, which I thought went pretty well.  We ran into some of the issues that often come up with pair programming, like being afraid to tell someone you don’t like their method name.

The second presentation I did was on Creating an Internal DSL for Automated Functional Testing.

You can find the presentation on Slideshare here.

We went over how to go about creating a good automation framework which fills in the gaps between the business language and technical language.

Thanks to everyone who attended.

The best example is one I’ll steal from Uncle Bob.  If you haven’t read this little dialog before, take a moment to do it now.   Paired programming is essentially two developers sharing one keyboard and mouse.  Both developers work together to write the unit tests and code to make them pass.  Often you will switch who has control of the keyboard and mouse.  I intricately tie together this practice with Test Driven Development (TDD), because a large amount of the benefit is in the ability for one developer to say, “Hey let me see the keyboard”, and write a unit test which will make the code fail.

Why paired programming?

There are many benefits some obvious and direct others as a side effect.  When you have two developers looking at the same code, you have two sets of eyes looking at the code as it is being written.  You have a much bigger coverage area of the problem domain, and are less likely to write bugs or miss something.  At the same time you are also having a live code review in the context of the code.  Also you are getting two developers familiar with the same piece of code, rather than “the dude who wrote all the DAO code.”  These benefits alone make paired programming worth it, but there are a few more.  Often one developer would get stuck on a difficult problem where two can easily push through.

Some of the indirect benefits are that when someone works alone they are less likely to be working.  Honestly, in an 8 hour programming day you might get 4 hours of work.  Now a good amount of this is due to distractions, like email, instant messages, random questions, not just slacking off (although some of it is.)  When you have two developers sitting at the same computer, it takes a larger amount of force to cause a distraction.  If someone is sitting at my desk, I am less likely to look at my email or be drawn away from the work I am working on.  You are more likely to get 6 hours or more out of two developers at the same computer with paired programming.

On the job training and cross training is another large benefit.  When you pair up a weak developer with a strong developer you will get the weak developer picking up the good practices of the strong developer.  Pair up two strong developers, they teach each other the little tricks that make them so effective and they both become more effective.  Pair up two weak developers, and you… get a mess for someone to clean up… Don’t do that!  Have a tester who should learn some development, pair them up with a developer or vice versa.  Even a product owner or business person can benefit from paired programming to better understand how the application is being developed.

Does it really work?

In my opinion yes.  I have personally seen the benefits over years of doing development work, practicing paired programming whenever possible.