JoergM.com

There are some obvious reasons why you should start blogging when you are a programmer. Most of them also apply to everybody else:

• You share your knowledge. This is a benefit for all of us. If everybody would be blogging about all the little issues they had then a Google-Search would help us even more. I am sure nearly every problem in the world is already solved. It is just not written down.
• It’s a kind of self marketing. A potential employer can get a much better picture of your abilities than he could from CVs or references. When I hire somebody it is already a huge plus for him when he has a blog at all.
• Explaining things to other people is the best way to learn. You can only teach what you fully understand. This is at least as efficient as hands on experience.
• You might even make some money with blogging. There are several sites about this. If you are interested look here or here.

But the main reason is something else. Some years ago I read an article about software documentation. There was a lot of wisdom in it, but one phrase sticked to my brain:

Programming is doing something weird to your brain. When you write a piece of documentation right after a programming session the result is likely to be barely readable for human beings.

If that’s true then the opposite should work too.  Blogging teaches you to write for people, which is exactly what you should do in your code. Good code needs to be easy to understand to be easy to maintain. There are whole books about this like the famous Clean Code by Uncle Bob.

I think blogging does something weird to your brain, that makes your code better readable for human beings. So:

If you want to become a better programmer, start blogging!

We all know those high-tech solutions that show the time left to a certain event. There are huge LED-Displays, Dashboard-Widgets or even iPhone apps.

For an upcoming release of our software a colleague installed a very low-tech version. You just need: a tape measure scissors a wall (a glass wall in our case) and something to attach the tape measure to the wall (some Scotch tape or Blue Tack will do) Attach the tape measure to the wall and cut a centimeter off each day. That’s it.

It should not be a problem to raise the budget for this solution. Most of the stuff will be around in any office. A tape measure can often be found in furniture stores for free, although a plastic tape measure for a few cents usually looks much better.
I love this kind of low-tech solutions. It’s a nice contrast to the high-tech around and even marketing can understand it.

I recently saw Bob Martins Keynote on Øredev. Around time index 14:30 he is talking about length of iterations. This reminded me on some experiences we made recently when trying sprints of one week in some of our teams. So here are some aspects we found.

The Good

• Scrum zeremonies are done very often. The people on the teams were used to scrum, but the teams were new. So the training effect of doing planning, review and retrospectives so often was good. By the way, the zeremonies are proportionally shorter. There is no waste of time just because there done more often.
• The short iterations gave a good feedback on where the project was going and how long this will take.
• The focus is very high on completing the sprint-tasks, but this is not only a good side. See also the Ugly.
• Teambuilding happens faster than with longer iterations. I think this is mainly, because teambuilding needs all phases of an iteration to be completed and shorter iterations mean the phases happen more often.

The Bad

• Tasks need to be prepared very well. A one week iteration is not only challenging for the team. It is even more challenging for the product owner. Tasks need to be well prepared and small enough to fit into one week.
• Some people on the team will not like such a short iteration. You need to get the commitment of everybody that they want to try this for a while.
• Things that go wrong, hurt faster and harder. This is good as long as the real reason will be removed. But it is easy to think of the short iteration to be the problem instead of the real reason.

The Ugly

• As already said, it is easy to get in a situation where the one week iteration is seen as the problem even if there are other reasons. This can remove this option for the future. So make sure the situation is ready, before you try.
• People can feel like being in a hamster’s wheel. This prevents from taking a step back and seeing the whole picture. Short sprints can show a lot of problems in the process, but they can hide larger issues or prevent alternative approaches. Everybody just feels they have no time for it.

So what is your experience with one week sprints? Is it just like Uncle Bob says: “It takes a real man to do one week iterations”?