Design/code reviews in a startup

#1

Post by johnnyice213 » Thu, Mar 20, 2008, 3:46 PM UTC

I'm working with 5 other developers in a startup-like environment (within a large defense company actually... go figure!). Until now our code base has been small enough that we've been able to get by without design and code reviews. However, our code base is growing as is our team.

There are several formal processes for doing this (Fagan inspection, over the shoulder, tool-assisted, etc.) A developer at MS even came up with a lightweight inspection (url: http://www.stickyminds.com/getfile.asp?ot=XML&id=7152&fn=XDD7152filelistfilename1%2Epdf).

The problem I see with a lot of these processes is that they interrupt your work flow and decrease productivity. I don't want to take an hour out of every other day to go through these reviews, but would it be too much to spend half a day every other week doing these reviews (and what would be the best day for this -- Friday?)

I think it would be great if we could get a discussion going about what others in similar situations have tried and what works and what doesn't?

Thanks all!!

Re: Design/code reviews in a startup

#2

Post by ambition » Thu, Mar 20, 2008, 4:04 PM UTC

A couple arguments in favour of inspections, Fagan-style:

- Although it takes a brutal-seeming amount of time, many teams get a net time savings thanks to earlier bug detection.

- It's a learning experience for everyone involved, so there is a deeper preventative aspect. This can be especially valuable for the new members of your team as you grow.

If you do inspections, and find just one bug that would have been nasty down the line, it's easy to emotionally understand the benefits. Without that experience it's hard to be convinced that it really works. Then again, you feel awful when you go through a 2-hour inspection with four people and don't find anything severe.

Be careful with Fridays, especially in the afternoon. In my experience meetings of any sort don't go well at that time. I'd suggest other weekdays around 10am or 2pm. These seem to be ideal for some reason.

As for frequency of inspections, it depends on how much code you're churning out. I personally think it's reasonable to only inspect particularly challenging, complex, difficult-to-test or critical aspects of the system.

Re: Design/code reviews in a startup

#3

Post by bayareaguy » Thu, Mar 20, 2008, 4:18 PM UTC

Where I work we use a simple version of Scrum.

Following the sprint review at end of every 2-4 week sprint, each developer either gives a short demo of the new features or changes they completed or a short review of the most significant code changes they made. Those who focused on features generally prefer to give demos while those who focused on bug fixes usually ask for quick reviews of just the most important changes. In total these meetings can go a few hours but they only happen on average once or twice a month so they don't interrupt the daily workflow.

We mostly just use our Trac wiki for reviews but I've been thinking of suggesting something like http://www.review-board.org when we get bigger.

Re: Design/code reviews in a startup

#4

Post by [deleted] » Thu, Mar 20, 2008, 4:23 PM UTC

[deleted]

Re: Design/code reviews in a startup

#5

Post by swombat » Thu, Mar 20, 2008, 5:13 PM UTC

Design and Code Reviews sit somewhere far on the slow-and-formal-and-clunky hand side of the spectrum between them and pair programming, but essentially achieve the same aims. Both pair programming and peer reviews (of code or otherwise) have the same aims and same results:

1) fewer bugs (peer reviews / pair programming is the most efficient known method to reduce the number of bugs, by far - testing is a distant second)

2) better spread of knowledge around the team

It's important to realise that they're the same tool, just twisted into a different shape. Pair programming is essentially taking the peer review concept and making it continuous rather than applying it at a regular interval.

In a startup environment, I'd recommend pair programming rather than code reviews, because it tends to provide a greater return, and it feels more nimble and fresh.

To ease yourself into it, you could start with pair programming days once a week, and see how people like it...

Daniel

Re: Design/code reviews in a startup

#6

Post by edw519 » Thu, Mar 20, 2008, 5:21 PM UTC

Good standards make code reviews trivial.

Well defined, zero tolerance, guidelines virtually eliminate the need for code reviews. Variable naming, standard routines, syntax, how to do iteration, branching, common functions, etc., etc. etc., should all be outlined clearly, agreed upon, and adhered to.

I prefer to look at it this way...

Code Review: No one gets out of this room alive until this is right (whatever that means).

Standards Compliance: Wanna play? Good. Follow the rules.

Oh, and please don't give me that age old argument about how standards limit creativity; if this small price for quality software is too limiting for you, then go play by yourself.

Re: Design/code reviews in a startup

#7

Post by dgabriel » Thu, Mar 20, 2008, 5:42 PM UTC

edw519 wrote: post #6

Good standards make code reviews trivial. Well defined, zero tolerance, guidelines virtually eliminate the need for code reviews. Variable naming, standard routines, syntax, how to do iteration, branching, common functions, etc., etc. etc., should all be outlined clearly, agreed upon, and adhered to. I prefer to look at it this way... Code Review: No one gets out of this room alive until this is right (whatever that…

I'm totally with you, but bear in mind that standards documents (especially within small start-up teams) tend to be built slowly over time, and reviewed and modified when necessary. Code reviews are great for establishing and tweaking standards when none exist.

Re: Design/code reviews in a startup

#8

Post by kingkongrevenge » Thu, Mar 20, 2008, 6:19 PM UTC

edw519 wrote: post #6

Good standards make code reviews trivial. Well defined, zero tolerance, guidelines virtually eliminate the need for code reviews. Variable naming, standard routines, syntax, how to do iteration, branching, common functions, etc., etc. etc., should all be outlined clearly, agreed upon, and adhered to. I prefer to look at it this way... Code Review: No one gets out of this room alive until this is right (whatever that…

> Variable naming, standard routines, syntax, how to do iteration, branching, common functions

You're seriously wasting time if your code reviews could be done by a batch of regular expressions and a cron job, ala http://search.cpan.org/dist/Perl-Critic/lib/Perl/Critic.pm

I always thought the point was to keep things well factored: find hard to spot duplication or inconsistencies in disparate areas of the code, point out a library/api that could have done the task better, etc.

Re: Design/code reviews in a startup

#9

Post by gruseom » Thu, Mar 20, 2008, 6:45 PM UTC

edw519 wrote: post #6

Good standards make code reviews trivial. Well defined, zero tolerance, guidelines virtually eliminate the need for code reviews. Variable naming, standard routines, syntax, how to do iteration, branching, common functions, etc., etc. etc., should all be outlined clearly, agreed upon, and adhered to. I prefer to look at it this way... Code Review: No one gets out of this room alive until this is right (whatever that…

Good standards make code reviews trivial.

If that were so, then you could standardize the production of good code.

Re: Design/code reviews in a startup

#10

Post by nradov » Thu, Mar 20, 2008, 7:14 PM UTC

edw519 wrote: post #6

Good standards make code reviews trivial. Well defined, zero tolerance, guidelines virtually eliminate the need for code reviews. Variable naming, standard routines, syntax, how to do iteration, branching, common functions, etc., etc. etc., should all be outlined clearly, agreed upon, and adhered to. I prefer to look at it this way... Code Review: No one gets out of this room alive until this is right (whatever that…

We have coding standards. The developers are good about following them, and some coding standards problems can even by caught automatically by static analysis tools.

But coding standards don't prevent logic errors, or requirements misunderstandings. Even the best developers make those kinds of mistakes and we catch a significant fraction of them during code reviews.

The other major benefit of consistently doing code reviews is learning. The attendees often pick up useful new techniques. And you spread knowledge of the code base around the team, which reduces the organization's dependence on any one developer and also brings out opportunities for code reuse.