Reading through some old documentation today written up a few years ago by our Agile coach I came across a suggested rule of thumb for code reviews:

• If more than X lines of code changed in a file then do a full code review of the file.
• If less than X lines of code changed you can just review the diffs.
• Developers should decide on where to set the bar for lines of code.

Strikes me as a pretty reasonable option. We’ve been reviewing whole classes except in a few circumstances, but we never set a rule on how many lines of code make it worth doing a full review. Maybe 20 lines is a good number.

After committing to Haskell for my new language in 2007 it was largely a failed experiment. I never found a good learning Haskell book. I went through a few tutorials and nothing really clicked much. I found myself wanting to hack around on Ruby rather than mess around with Haskell syntax.

I really prefer a comfortable well-written book introduction to a new language. Something like the Ruby Pickaxe book or Learning Perl. Maybe this year will be Erlang or Common LISP since they both seem to have nice introductory books available.

I was cleaning out the closet today when I came across this cute little onesie from an old dotcom I worked for. I had my first daughter while working as a web development manager for XUMA. She never actually wore the onesie because it got packed up in a box for our move to Sacramento.

We were an e-commerce vendor doing a lot of projects on ATG Dynamo. There was an attempt to morph into a product company selling ASP services or in the new Web 2.0 world, Software as a Service. I’m glad the ASP model has finally become common place. If you need some functionality like a CRM, managed hosting, or security monitoring you usually a lot better off just utilizing an ASP option.

Recently Uncle Bob talked about a manager who constantly choose short term hacking over anything else defending the decision with the idea that “business software is ugly.” Uncle Bob came up with a good argument to make:

One of the developers asked the question point blank: “What do you do when your managers tell you to make a mess?” I responded: “You don’t take it. Behave like a doctor who’s hospital administrator has just told him that hand-washing is too expensive, and he should stop doing it.”

For many developers trained through experience that speed is more important than quality it’s difficult to resist being asked to develop a feature faster. Hacking just adds debt and slows down future development. It’s the sort of thing where an application has gotten so complex and hairy that a developer new to the project can’t even be productive for a month or two. Just getting up to speed on how the beast has been hacked together wastes weeks of time.

Kudos to Uncle Bob for using a powerful analogy to make people think.

I heard a good story on one shop where they actually had a KitchenSink class in their codebase to dump things they really couldn’t define a context for. The point was they were at least being transparent about their failure to find a better place to put something.