What is a good measurement of the quality of your architecture? The length of your documentation. The shorter, the better. There are three purposes of documentation that can be important to a project for its long time survival. First: How does a new developer get started working on the project. Second: How do you install the projects executable on a brand new server. Third: What do you have to know to monitor and operate the system.

I got this one from xkcd via Chris Searle. It’s now posted on the walls at work:

I went to Simula Research Lab’s seminar on estimation today. My conclusion is that despite many years of practice and research, we don’t know how to make estimates for even moderate projects correct within an order of magnitude. I think a new approach is needed! I wish I could’ve said that I learned something fundamental, but instead, I got my preconceptions confirmed. I think I understood the underlying causes better, however.

The Norwegian word “smidig” means “agile”. So when we wanted to make a Norwegian conference for the Oslo Agile community, “smidig 2007” (November 26th and 27th) was a natural choice for a title. The seed of the conference was idea by Nils Christian Haugen and Aslak Hellesøy to have a whole day devoted to open spaces. Meanwhile, I had been experimenting with “lightning talks” on Oslo XP meetup, a user group that meets in Oslo every month.

My presentation at JavaZone was riddled with technical difficulties this year. To make a long story short: I learned five minutes before the presentation the the projector would be inoperative for a while (turned out to be 30 minutes). This threw a wrench into my plans, as I had planned to open with a demo. I have read many times on presentation zen about presenting without slides. But before I stood in front of four hundred people with nothing to look at except me, I didn’t really believe how effective it would be.

My talk at JavaZone went surprisingly well. The fact that the projector went dead and that I was planning on opening with a demo raised my pulse, but I felt I managed to get my message across and that people were happy. The talk was about how we use Jetty to manage the full deployment life cycle of our application. I explained how we had implemented this and what problems we had solved.

“I just feel that in this company, there’s too many chiefs and not enough Indians.” “Sure. Now, if they’d only been Indian chiefs.” I have been real quiet lately. I will try to be better about writing in the future. I’ll do my best to stay away from project management issues, though. I’ve stepped on enough toes lately, I think. Here are some teasers of upcoming topics: REST, Quaere, introducing tests into existing code bases, the Norwegian conference “Smidig 2007”, my JavaZone talk, and closures for Java.

Sometimes, a quick and easy programming language like Ruby might not be so quick and easy. Sometimes, C may be easier. Sometimes, you might complete a task faster with C than with your favorite scripting language. I’ve long been a proponent of scripting languages. In particular, I’ve enjoyed learning and using Ruby. So when I was inspired to program a boggle solver as a code kata, I naturally reached for this nice shining tool in my toolchest.

Anders Nordås shows how to throw a checked exception without declaring a throws clause. The method uses some inherently evil mechanisms (the name of the class “sun.misc.Unsafe” should be a tip of), and like Anders says, this should probably never be used in production. Basically, calling sun.misc.Unsafe.throwException will throw a checked exception without alerting the compiler. The exception is not wrapped, but it cannot be caught by its class name, as it is not declared.

Why can Scrum deliver surprising results already in the first month of adoption? Because it helps the team focus on what’s really important. We had Jeff Sutherland visit Oslo XP meetup a few weeks back. Jeff is co-creator of the Scrum method (with Ken Schwaber) and CTO of PatientKeeper, a US health information company. His presentation focused on the effects of Scrum on distributed teams, and on the effects of adopting Scrum in projects.