If you ever talk to a group of people, you know that the art of presentation is one that requires a lifetime to master. But there are some dirt simple things you can do that will have a positive impact on your presentations. Here is my list of low hanging fruit for presenters: If you’re using a computer, use a presentation remote. This is a cheap and easy way to make your presentation style look a little more professional.

[caption id="" align=“alignleft” width=“165” caption=“Unstructured picture”][/caption] I recently started on a new project. Looking over the code base, I saw the familiar structure of many projects: Definitions of classes goes here, persistence logic goes over there, interfaces to the persistence logic goes this other place, code for transforming from one structure to another in yet another place and so on. This is common, neat, and unfortunate. As an exercise to understand the architecture of this system, I decided to add some new functionality: Displaying some data to the user.

“The service went down because another service running on the same application server went down.” “You can’t use the improved version of your programming language because you’re running on the same application server as some old applications.” “We can’t help you deploy your application on the application server, because we’re busy with some other application.” If you’ve ever heard any of these statements, you’ve been victim to the accidental complexity of the application server.

Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: “You know, I really should do something about that… but I don’t have time just now”? On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it? When I start a new project from scratch, there are no warnings, no clutter, no problems.

Top five signs that you might not be working on an agile project: Your iterations do not produce anything that could be put into production You’re not testing your work You tasks are called “code the UI for the foo”, “update the bar component” and “test the work done in the previous iteration” Your iterations are called “specification”, “testing”, and “preproduction” And the top sign that you might not be working on an agile project: You might not be working on an agile project if your iterations are three months long Happy Holidays, Merry Christmas and Happy Monkey, everybody.

I’ve been part of the group organizing the Norwegian language, lightning talks based conference Smidig the last two years. This Norwegian language article describes the essential guidelines to giving a short presentation. En god lyntale kan ha enda større påvirkning enn et godt foredrag, fordi lettere kan nå flere mennesker. Men det krever innsats. En god lyntale er: Fokusert: Du skal ha ett poeng, én påstand eller ett spørsmål som foredraget bygger rundt.

I became a programmer so that I could spend time creating software by programming. I don’t want to waste my time managing low-quality code. Does your code work the first time your test it out? Mine certainly never does. So if I hand over the code to someone else, I’m sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers.

The Norwegian computing association has released guidelines for contracts regarding agile projects. Wednesday, November 26th I will be part of a panel debating this work and the combination of agile and contracts. This Norwegian language blog post contains my introductory remarks for the debate. Kom på debatten på Oslo Lean Meetup på onsdag og delta på debatten! Jeg er ikke en prosjektleder, en advokat eller en politikker, så jeg kan ikke si så mye om hva som må være med i en slik kontrakt.

Agile software development has learned about informative workplaces and stop-the-line quality management from lean manufacturing systems. Here are my implementations of it at my last project: All is well This video shows how our project looked when all is well. The large green light in the front shows the status of our build server. The green flashing lights show the status of our staging and production server. For the production server, the frequency of green blinks indicates the load of the system for the last 10 minutes relative in % to highest load ever observed.

Update Thanks to Alan Palmer for this trick that makes this whole post unnecessary: If you use !path {java.class.path} You get the classpath that fitnesse was called with, without the need for changing the fitnesse code. Regular readers of my blog may remember that I’ve researched how to get the classpath from the FitNesse-process inherited by the Fit process that FitNesse spawns when it runs a test. This trick is an easy way to get around having to specify classpath variables in your FitNesse tests.