I’m looking into moving some of our projects to some form of a tool-assisted code review process. The intent is to stay clear of traditional ‘big company’ reviews and all the emotional baggage that goes along with those. The goal of our reviews will still be better quality, more maintainable software, however, almost equal to that is to generate team collaboration in the context of actual code.

This is about mistakes and finding them, however, that cannot be a negative experience. To state it the other way around, he who makes the most mistakes wins. This will be about finding mistakes as early as possible, learning from them, and moving forward. If you fail on that part and drift into using the number of mistakes as a carrot or stick then you’ll build development teams that are very good at hiding their mistakes which is terrible for everyone involved.

Bugs are good. Mistakes are good. If you aren’t finding mistakes then something’s broken. Your testing could be broken, your developers may be hiding or not fulling disclosing bugs. Another, equally bad possibility, is that your developers aren’t pushing themselves and are instead only doing what they are 100% certain they can safely deliver. If that’s the case then I guarantee you that you’ll be sitting in a meeting someday soon titled “How do we get our developers to innovate?”.

I’d like to try an open source product but at this point I’m most impressed with what SmartBear has. Some related links:

http://smartbear.com/docs/BestPracticesForPeerCodeReview.pdf
http://www.ganssle.com/Inspections.pdf

and a free book offer…
http://smartbearsoftware.com/codecollab-code-review-book.php

I only saw this related post now, I swear.

Timothy Ferriss is getting a load of press these days for his recent book. He also has a nice preview of the book available in the form of a ChangeThis manifesto.

I haven’t read the book so I can’t comment on it directly. I do know that one of his key suggestions is to take control of email. I’m in complete agreement with him on this, however, I’ve managed to drift away from the practice in the past two years.

The basics? Close your email client. Only open it once or twice a day at explicit times.

I first began practicing what is essentially the same thing Timothy suggests back in my MKS days. I was inspired to do so after reading The Tyranny Of Email, written back in 2003.

In short, I’m working my way back towards this. The migration is less about my email habits than it is people’s expectations of my habits. Everyone’s used to me responding almost instantly so I need to work them towards a new pattern. Or technically an old pattern that I somehow abandoned.

If you’re in a rush to get back to your email, Ole has a great summary:

1. Turn your email client off. Pick the moment at which you’ll be interrupted.
2. Never criticize anyone in email, and avoid technical debates. Use face-to-face meetings or ‘phone calls instead.
3. Be judicious in who you send email to, and who you copy on emails.
4. Observing some formality is important.
5. Don’t hesitate to review and revise important emails.
6. Remember that email is a public and permanent record.

Wow, at first I thought this was interesting in that David was taking a job with Microsoft. The post IS interesting but the comments contain the real meat, including drifting into a comparison of Microsoft to a certain supremacist group. Congrats on the new gig David and for once again generating some amazing dialogue.

PS: I have to admit I keep checking to see if it’s April first. David Crow….Microsoft…..it’d make a great April fools prank.

Good list and I agree with pretty much all of it. It’s the parts you don’t predict that are the most surprising, like the Dilbert comment and being hard to say no.

Anyone who knows me knows that when I was in an office I was fairly in tune with the ‘politics’ around me. I really never thought I’d get to a point where friends in an office would complain to me about common annoyances and I really wouldn’t get it or have much to say. Well I’m at that point now and have a lot of those “oh man, I forgot all about that crap” conversations. That’s a great thing.

I suppose when I return to a traditional workplace I’ll be like a home schooled kid showing up for the first day of high school.

It’s been a while since exceptions cropped up here. While this isn’t ‘hot off the presses’, I’m certainly just catching up. When the boys at Microsoft originally built the .NET framework, they added a base exception class named ApplicationException. They suggested, and illustrated themselves in any related example they wrote, that custom exceptions in your application should extend from this instead of the base Exception:

“User applications, not the common language runtime, throw custom exceptions derived from the ApplicationException class. The ApplicationException class differentiates between exceptions defined by applications versus exceptions defined by the system.”

If you read past that paragraph then you’ll discover that this class is essentially a dead class now:

“If you are designing an application that needs to create its own exceptions, you are advised to derive custom exceptions from the Exception class. It was originally thought that custom exceptions should derive from the ApplicationException class; however in practice this has not been found to add significant value.”

Of course they don’t go out of their way to explain why there isn’t “significant value”, however, Brad Abrams does here. Actually the explanation is in the post comments:

“When first reading Mr. Richters advice on not using ApplicationException I was stunned, but it actually make sense. If you create some application specific exceptions you may want to derive these exceptions from a common base class in order to be able to catch them all in a single catch clause. Deriving this common exception from ApplicationException doesn’t add anything useful to your exception hierarchy - it just deepens it.”

Basically MS deepened the exception hierarchy without adding ANY value which is rule #something of designing quality custom exceptions:

“Designing exception hierarchies is tricky. Well-designed exception hierarchies are wide, not very deep, and contain only those exceptions for which there is a programmatic scenario for catching. We added ApplicationException thinking it would add value by grouping exceptions declared outside of the .NET Framework, but there is no scenario for catching ApplicationException and it only adds unnecessary depth to the hierarchy. You should not define new exception classes derived from ApplicationException; use Exception instead. In addition, you should not write code that catches ApplicationException.”

In reading about strategy in Hard Facts, it’s clarified where I think Band of Coders should be heading “strategically”. That is to be a company that tries different things in order to learn through the process of experimentation. Evaluate what works and continually develop our competencies and skills as we evolve as a business.

Sure is easy to say.

There’s some video and a write up here if you’re asking that question.