programming

There are 28 posts filed in programming (this is page 3 of 3).

Smart Bear Software – Peer Code Review Book

A while back I promised to read and review Smart Bear Software’s book “Best Kept Secrets of Peer Code Review” – I read the book right away, but haven’t yet made the time to actually write up a review – so let me give a brief review now: I like it.

The book is easy to read, with a relatively conversational style of writing. It covers “old school code review” – big formal affairs – and introduces lightweight code reviews as well. It also presents results from a number of code review studies (including Smart Bear’s Cisco study which they call “the largest case study of peer code review”) which show that code reviews of any form are a good idea.

The book is a good summary of code reviews, and Smart Bear’s brand of lightweight peer code review sounds like a great way to implement them.

Hot Wasabi, Hot Jobs

Conspiracy theory:

Joel posted his Language Wars and Wasabi posts on September 1, 2006.

He announced the new Joel on Software Jobs Board on September 5, 2006.

Hmm… Joel knew that his Language Wars and Wasabi posts would get a lot of attention, and perhaps some of that attention would last long enough to get a few extra people to notice the new jobs board…

Was the timing of those posts intentional? 🙂

(Yes, I know, Joel gets plenty of attention any time he says anything, but the Ruby comments alone seemed to generate more than the average amount of chatter.)

Smart Bear Software: Lightweight Code Review presentation

A couple weeks ago I saw a great talk by Jason Cohen, founder and CEO of Smart Bear Software about lightweight code review (pdf of slides).

A quick summary of Jason’s talk:

  • Up-front code review saves time and money by finding bugs earlier (backed up this claim with real world data).
  • Smart Bear has a product called Code Collaborator which “enables peer review of source code changes before or after files are checked into version control.”
  • His emphasis was on the process of code review rather than Code Collaborator, though he got plenty of questions about the software.
  • They did a big study with programmers at Cisco (“the largest-ever case study of peer code review”), talked about the results.
  • The most effective reviews are for less than 200 lines of code and take less than 1 hour.
    • Maybe you can do 400 lines and 1.5 hours, but that’s pushing it.
  • Positive social aspects of code reviews:
    • “ego effect:” knowing that someone else will be looking at your code may help you be a better developer immediately
    • you may learn a thing or two by seeing how others code
  • Create an atmosphere where finding bugs is good – whether you coded them or not. Bugs found here and now are much easier and cheaper to fix (and less embarrassing!) than bugs that turn up after you ship.

Jason was truly excited about this stuff, which helped made it a great presentation.

Jason (& company) wrote a book about lightweight code review called “Best Kept Secrets of Peer Code Review” – they’re offering it free (as in beer) from their website – that book title link will take you there. I just received mine in the mail and I’m looking forward to reading it.

(Yes, I read stuff like this in my spare time. I am, in fact, a geek. And proud of it. Of course if you’re reading this far odds are you too are a geek, so you’re not surprised.) I’ll write more as I read the book.

Herding Cats at Google

From an Information Week article about Google:

“Lots of small, short-lived projects mean traditional project management software based on task lists isn’t right for Google. For one thing, techies aren’t very good at cataloging how they spend their hours. What they are good at, it turns out, is writing up a few short sentences or snippets about what they do each day. Those get compiled in a database along with periodic updates from project leaders about a team’s deliverables.”

(That link is from page 4 of 5, fyi.)

What’s more important to a non-consulting / hourly billing company – (A) tracking the number of hours employees work or (B) tracking the actual work done?

Hmm, let’s see:

  • (A) Tracking the number of hours worked doesn’t necessarily tell you how much work was done. It may give you a hint, but what if you’re having a day like Joel sometimes has?
  • (B) Tracking the actual accomplishments tells you exactly how much work was done. You know where the project stands relative to its milestones.

From a “how is the project doing” point of view, option B seems to make a lot more sense. Getting Things Done is what makes money. More hours will probably lead to more work being done, but why use a second order measurement when the first order measurement is available?

Plenty of people who are smarter and more eloquent than me* have discussed why you can’t just measure “techies” by the number of hours they work. I’m glad Google is doing something better. Meow.

* I’m not even smart enough to know if “me” or “I” is the right word there.

Svec on Joel on Software on Language Wars

I was hoping to cash in on the popularity of Joel’s post, but then I noticed that everyone and their computer-illiterate grandmother who doesn’t have electricity has already commented on it, so I’ll just throw in some links:

Okay, I’ve got to throw in my 2 cents:  Joel drew a line in the virtual sand (silicon?) – not a very thick line, a medium “I stand over here” kind of line – and people started hurling themselves on one side or the other.  It’s interesting to see how many people seemed to be threatened by Joel’s post as if it was a personal attack against their professional way of life.

I think Joel was simply being honest – and because his company is successful he knows he’s right.  Sure, he makes some generalizations that might be a bit exaggerated (though not much, says I), but he’s got the results to back up his rhetoric.

Thoroughly entertaining – an excellent way to start a 3 day weekend!

Fast, Cheap, Good

“Tradeoffs: Fast, Cheap, Good – Pick Two.”

That saying is usually depicted with a triangle – each edge or point of the triangle has one of the words on it. Kind of a binary (or ternary?) thing:

  • You can have Fast and Cheap, but it’ll be lousy.
  • You can have Fast and Good, but it’ll be expensive.
  • You can have Cheap and Good, but it’ll take a long time.

The simple Pick Two decision implies that your project will be lousy, expensive or will never be completed in the first place – in other words, a failure. I think the choice is not that simple – nor should it be.

Vivid Media has a nifty interactive slider graphic that is more realistic than the Pick Two scheme (and it’s so much cooler than a plain ol’ triangle, too).
Each Fast, Cheap and Good slider moves a bit up or down as the other sliders are moved – it’s not strictly an ON/OFF relationship. There is more granularity than simply “fast or slow,” “cheap or expensive,” and “good or lousy.” These degrees of choice should be considered as a continuum of interrelated options – I think this is a much better way of thinking about the “What are the tradeoffs?” question.

Edit: Niksilver.com has some interesting comments on “good.”