This had be laughing out load:

Read the rest, it is funny.

I am searching for a tool to help with code reviews. This is something that is done after the fact, not before commits, by the way. Specifically, what I am thinking about is a tool that let me browse checkins into the source control, select one for review, add comments to it, etc.

I wrote the above sentence, and then went to Trac, and took a look at the Timeline view. It seems to be that this may be a way to do it, while handling the code reviews as tickets in Trac as well.

At any rate, I would like to be able to get a tool that says what has changed and needs reviews, or able to give me a diff over more than a single commit. I just thought of a new thing that I would like, something along the line of getting all the changes in this directory from last time that I reviewed it. I can get a diff from subversion, but attempting to understand something with just a diff is non trivial.

Any recommendatiosn about tools for doing this?

Stefano Demiliani has a post about this, and he gives the long way to do it.

Here is the short way...

I am posting it because you can't use an image in a comment.

That is what Microsoft thinks that I am ;-) Take a look at this horrifying video, detailing how I was reduced to begging in order to get to the event. At least I end up arriving in style :-)

At least I wasn't turtored, thrown off a plane, sent to space or Telenovelled.

Seriously, that is nearly 5 hours of my life, compressed into 40 seconds. For those of you who aren't Hebrew speaking, those are teaser videos for the Microsoft Academy Event at the end of the month.

Dan Bunea had published a very good tutorial about how to do Test First development on the web.

Go visit here

Brian Harry gives an interesting perspective on why Microsoft will not publish the full lists of bugs that were fixed in VS SP1:

That is really not an acceptable answer, as far as I am concerned. I can at a moment notice gives you a list of all the bugs that were fixed in NHibernate 1.2.Beta3. That is because NHibernate is using a magic system for Bug Tracking. This new approach means that bugs are no longer live in a coder's dream, or on a post-it note, but on a database. This radically new concept is still absent in Redmond, I am given to understand from the reply above.

More seriously, you ask me to download half a gig, give up my machine for an hour best case (days or worst if it is not) and you won't tell me what was fixed? To take a simple example, there are two performance related bugs in the list that they did published. Yet this release is supposed to:

I am a developer, I don't deal with overalls. I want to see what was fixed, even if it means just having bullet points.

Can you spot the bug in here?

It is a very nefarious one...

Joel has another post, and this quote just killed me:

To make things fun, add a non-technical project manager to the mix, that just asks every now and then "how much time it will take?", a business analyst that can't understand a word of what is going on and keep trying to turn a discussion about how to manage user's permission in AzMan into a discussion about what the website should look like. It is best to gather people from at least two other teams, completely unrelated to the subject at hand, but whose roadmap shows that in two years, they may need to have a similar feature.

To make things really fun, add two consultants, each with their own agenda about the products that they want to have, each of them as the representive of a different manager with political rivalry. At least three people should be on a long distance conference call, and there is someone that keeps coughing. Oh, and there is a salesman trying to convice the janitor that their product will make them work Real Easy and It Really Works Now!

Sigh...

Last week I had two days with no meetings. I think that I managed more work during those days than in the last two weeks combined.

Oh, and the rest of the post is really good as well, as usual.

Moran commented on my Thinking about Developers post, and it got me riled up enough to post an immediate response*. Here is his comment (emphasis mine):

Sorry, I don't see it this way. Drag and drop programming works for a very narrow scenario, when you are in an assembly line, endlessly producing similar pieces of software, never going back to maintain it. How often is this the case?

Quoting Wikipedia:

This means that anything that can make it easier to work with the software is going to drastically improve the cost of working with the system. Hell, the moment I have written more than three lines of code, I get into maintenance mode. And you know, that scenario that I outlined above, I can still be more productive using smart tools and frameworks than any Drag&Drop assembly line worker.

The problem with Drag & Drop is that the real cost of this method begins to show itself three months into a project, when most people are afraid to say: "We have to throw this mess and start over with a clean slate**"

* Yes, Moran, I do assume that you didn't mean to advocate Drag & Drop programming.

** Even though I am a big believer in not throwing code away. (I am a huge believer in throwing snippets of code away, which may be large snippets).