Friday, August 31, 2007

Managing humans

Michael "Rands" Lopp has written a book called Managing Humans. I already blogged about this guy it in the past. I consider his book essential reading for every developer, but also make sure that your boss gets a copy ;-).

Wednesday, August 29, 2007

The Myth of Software Estimation

Just read an excellent blog post on The Myth of Software Estimation. The author claims that the relationship between humans and computers is just as unpredictable as a relationship between humans. I agree (nice analogy B.T.W.).

Ayende has a similar post about the fact that You can't estimate a month. I agree. My opinion is that you can plan your activities for one week at most (and even then for this short period of time its sometimes very hard). That's why I'm very much into one week iterations. Composing a sprint backlog for one week is a somewhat realistic thing to do, while composing for one for one month is not. 

The subject of estimating software development is intriguing (at least it is to me). We can't seem to get this aspect of our job under control. There's some excellent literature available that covers this topic that I haven't got the chance to read (yet):

Maybe this is something we need to consider when talking about becoming better developers?

Friday, August 24, 2007

Tools, tools, tools and ... tools

A good craftsman can be recognized by the tools he's using. Therefore its time again for the world famous, ever growing Scott Hanselman's 2007 Ultimate Developer and Power Users Tool List for Windows.

If that's not enough, give the excellent book Windows Developer Power Tools a read. You won't regret it.

Wednesday, August 15, 2007


Another must-read post by Jeff Atwood on how Discipline Makes Strong Developers. I couldn't agree more. Only discipline on the part of the developers makes code that is concise and easy to maintain. Having an eye for detail is one of the core skills of every developer.

Currently I'm reading the book Inside Windows Communication Foundation by Justin Smith. One of the code examples in his book contains the following piece of code:

// commented out for clarity // Console.WriteLine("{0}\n", message.ToString());

I'm sorry, but this doesn't clarify anything. On the contrary, I actually found the code sample in question more difficult to read.

At some point in our careers as a developer, we inherit some piece of legacy code. I don't know about you, but I already had my share of legacy code that was sprinkled with lines of code that were commented out for some reason. This proved to me that the last developer who worked on this code-base was simply undisciplined and didn't care about what he was doing. He didn't bother to cleanup his mess after he stopped working on the project. Some would argue that it shows the history of the code that went into production. We have source-control systems for that, people! When I see these kinds of code, the lyrics of It's Time For Violence just cross my mind. 

Again, good code should read like a good book. Good code should invite others to read it. Good code is all about the details. Writing good code that is easy to maintain takes lots and lots of discipline.

Thursday, August 02, 2007

Visual Studio 'Rosario'

According to this this article, Microsoft is releasing a first CTP of Visual Studio Rosario somewhere next week. I don't know about you, but I'm running out of space with all these virtual machines.

Update: You can download the bits here.