Over the past year I’ve done several presentations at user groups and conferences on the topic of refactoring. In this talk I shared some of my knowledge and experience with refactoring. Even though I am not the biggest refactoring expert, I believe that I know enough to share it with people interested in the topic. Every time I did the presentation, I was happy with the message I got across, yet not completely satisfied with the way I got it across.

When Ibuildings internally launched the TechPortal initiative and did a call for writers, I immediately took the opportunity to propose an article on refactoring. I thought it was a logical follow up to the talks I’d been giving on the subject. And indeed it was. Yet, as I was writing the article, more and more the feeling creeped up to me that I should’ve done this way earlier. I should’ve done this even before doing my first talk on the topic.

At first I was a bit confused. How could it be possible that I’d been working on this presentation (and the various incarnations of it) for quite some time, and not be satisfied with my presentation and slide deck, yet now that I was writing on the topic, I got a very clear idea of how to approach the presentation. But actually it makes a lot of sense!

When, like I did with my initial refactoring talk, you start preparing a presentation based on your own experience, you work on a short outline, and then on the slides. At least, that’s the approach I took. You order your thoughts very globally, because the only things you need to actually save are the outline and the slides. Even though you consider all the information you will be presenting, most of it stays in your head. And at least in my head, information isn’t as structured as, for instance, an article.

And this is where writing the article helped. I really had to structure the information much more in the article than I had done in my head and on the slides for my presentation. Because you don’t just put the outline into that article, you have to actually write all the information down. An article needs to have a good structure, present all information at the right time and in the right context. And even though writing the article is something completely different from preparing a talk, having the information in such a structure helps a lot in getting the information straight for your talk.

Now, the article at TechPortal is scheduled to be published in a few weeks, but already it is a success to me. I’ve used this new, more structured approach to the refactoring information when I prepared my refactoring talk for the 4developers presentation in Krakow. And having done the presentation, I am much more happy with it myself, I’ve gotten much better feedback from the attendees, and also Ivo, who has attended both my refactoring talk at PHPNW ’08 and the one in Krakow, said the latter one was much better. This feedback decided to make me share this experience.

So, if you are going to do a talk, and you can’t really get your head around the right structure for the talk, write an article. You could write the article for your weblog, for php|architect or another magazine, or not even publish it but just use it for yourself. The writing itself is more important than where you publish it, as long as it helps you in getting the right structure for your presentation.