On Thursday 4 February 2010 Marlous gave birth to our first child. His name is Bor and his weight is 3340g.
Of course we think it is the most beautiful baby in the world, but you can judge for yourself:
Yesterday I cam across the following cool presentation tool prezi and decided to give it a try. Here’s the result (toggle full screen for better view):
After this toying around I am definitely going to use this tool more often. Not only for some presentation, but probably also for creating one or more mind maps.
This week I joined on a new project. When I wanted to change some class, I encountered a singleton that kept me from writing good test cases without jumping through some hoops.
This annoyed me, but then I wondered…”Why have I never used a singleton?” I am aware of the GoF patterns and value their use. Sometime I use them as a solution and sometimes they emerge while refactoring. In my opinion their greatest value is they provide a means of communication.
After some research my conclusion is that of many others: If you are tempted to use a singleton: DON’T. When you cannot come up with a different solution: Google for it or discuss your problem with some colleagues. When the best solution still is a singleton: Let me know.
The problems with the singleton are summed very well in This post from Scott Denssmore:
- They are mostly used as a global static.
(We agreed these are bad right?)- They allow you to limit the creation of your objects
(This is not the responsibility of the class)- They promote tight coupling
(While we strive for low coupling, tight cohesion)- They carry state the entire lifetime of the program.
(Object state is the source of very annoying bugs)
The singleton I encountered suffers from problem 1,3,4. Time allowing I will gradually factor out this beast that is littered throughout the entire application. But this will require some negotiation with the rest of the team.
To provide some perspective I suggest also reading the comments and the following response from Matt Berther: Singletons are not evil. I have to agree with him. The singletons pattern is not evil, it is just a pattern. But I do think using singletons is, thus my conclusion is that ’a good singleton’ is an oxymoron.

Did you ever get bored or distracted during yet another presentation? Maybe you even fell asleep? I know I have. What’s even worse: people are so used to bad bullet-point infested slide shows this has become some kind of standard.
The problem with these presentations is that the words get lost between the bullet points. With a lot of good intentions someone is delivering a message, but no one remembers it. In terms of lean manufacturing, such a presentation can be classified as waste. Waste for the presenter, because his message did not arrive. And obviously it was a waste of time for the audience
But there is hope. I’m not the only one getting tired of the same old presentations. Actually, the war against bad presentations already started a long time ago. A lot of people are trying to get rid of bad presentations. But the person who inspired me most, was Garr Reynolds.
Reading this blog, I accidently stumbled across Garr’s book presentation zen. Because I was in the process of creating one, I ordered the book and it opened my eyes. It showed me what is wrong with most presentations today and how to improve this. As far as I’m concerned Garr succeeded in the goal he mentiones in the introduction of his book:
… if I could begin to help others look at preparation, design and delivery of so-called “powerpoint presentations” in a different way, perhaps I could do my small part to help others communicate far more effectively.
After reading the book and having learned from it, I decided to join the quest of helping others to communicate better.
My first act was putting my newly found knowledge to practice by doing a presentation at work on presentation zen. From the audience of 25 people I am positive I convinced at least two listeners to buy the book. And everyone in the room will think differently the next time they are listening to some talk or creating one.
My second act is writing this post, in the hope to reach a few more people. As you might have guessed I highly recommend buying presentation zen and learn from it. Besides the book, there is also a wealth of information to be found on the blog and website. If you value the information as much as I do, I urge you to spread the word. Only by doing this, presentations will become more fun to give and more interesting to watch.
On Saturday the 29th of August I participated in the Tilburg swimrun. This was the first time I competed in such an event, and it was a fun experience. Here’s a short report.
Swimming 750m, I came in fourth at 16′07.
Ran 5km in 30′17. Including putting on shoes/shirt. But yes, I’m not a natural born runner.
Finished exhausted, sixth out of ten at 46′26. Not bad, considering this was the first time. Have to improve my running though. (Going to run 15km in November, so I still need some serious training.)
As I mentioned previously, I’m writing a series on interesting anecdotes I’ve heard. Here’s the second one.
My girlfriend and I like to cook (and eat). One the favorite recipes my girlfriend likes to cook is a turkey baked in the oven. It’s a famous family recipe, which has been passed on from mother to daughter for generations. The steps for making this lovely dish are somewhat like this:
The end result really tastes marvelous. But, knowing a bit about cooking myself, I wondered why the two pieces had to be sliced from the turkey? I asked my girlfriend, but she didn’t know. She learned to do it like that from her mother. She asked her mother, but she also didn’t know. Her mother learned to do it like that from her mother…
Finally, after some investigation, the truth came out. In the old days, when my girlfriend’s great grandmother made this recipe, her oven and baking dish were too small to fit an entire turkey. That time, she was forced to cut off the two sides to make it fit.
This is a story on following processes blindly. Since we are creatures of habit, this is something that easily happens. There is some problem, we find a solution and stick to this. Because our solution works really well, we tell others about it. Then we formalize our processes, to make sure that our old problem does not reoccur. But when our context changes (our oven gets bigger), our way of working might need rethinking.
Here’s a simple example: A lot of coding standards demand that variables should be prefixed with their type and/or scope. (e.g. mp_strAddress) This law might have its use when there are people developing with an editor as limited as notepad. But most modern IDEs provide tooltip information, while hovering over a variable. With this tool available, is it still valid to enforce prefixing of type information? (Also think about the prefixing of member variables.)
We should be aware that we don’t get locked in old ways. If someone asks: Why the … are you doing this? You might hear yourself talking about preventing some academic problem. (Or worse, you might mention it is the way it has always been done, without knowing why.) The best response in these scenarios might be: It looks like I’m slicing the sides of a turkey, I wonder if this still valid?
After asking yourself the question, you can still conclude that what you are doing is still valid. And again you have sharpened your saw.
This story was told to me by Lee Copeland, writer of this book. During his workshop he told lots of valuable stories. You’ll probably find me contributing more anecdotes to him.
At my work we are trying to keep people aware of agile practices. During an agile course I learned that we use practices, because we value something. (And principles can be regarded as a rule or code of conduct.)
To aid in the quest of boosting agile practices, I made the following A3-printable versions of the agile values and principles. As a bonus I added the manifesto for software craftsmanship, because I personally value it’s statement.
They are here for you, so you can also stick them on the wall of your office as a subtle reminder.
As
someone eager to learn, I constantly feed my craving for information. On this quest for information, I encountered a lot of valuable ideas packetized in anecdotes. The clues of these anecdotes sometimes seem silly or obvious, but they have superpowers. First they are true and second they seem to stick. At appropriate occasions, I have found myself telling them to team members. We smile about them, but after that we regularly keep refering to them. Especially when we need a reminder of the pitfalls or our daily work. You will find these anecdotes appearing on my blog, starting with the following.
Imagine yourself walking through the woods on a bright, sunny day. Down the path you see a lumberjack sawing down a tree. The man is working very hard, moving his saw back and forth at a high pace. As you approach, you notice that he is not progressing very fast. On the contrary, when you get even closer, you notice the cut he is making is not getting deeper at all. This guy’s saw must be blunt!
Nice as you are, you decide to give the man some free advice: “Hello mister lumberjack! I have been looking at your hard labor and noticed the cut you are making is not getting deeper. It looks like your saw is blunt and you might want to consider sharpening it.”
The man shortly raises his head and replies: “That sounds like an interesting idea. But I don’t have time to sharpen my saw. I really need to saw down some more trees.”
That’s it, the punch line you can use to remind eachother: Take time to sharpen your saw. When working constantly at a high pace, you might find yourself in the same situation as this poor lumberjack. Being extremely busy, working very hard, but making no progress.
Here are some examples of opportunities that might slip by:
(Note the wish, excuse-for-not-doing-it pattern.)
The story about the lumberjack tells us to take time to learn, reflect and improve. By taking time to do this you will make progress faster. During my work I noticed that saw sharpening can be done in different ways and by different means.
Also teams can benefit by taking time for sharpening their saw. One of the best ways I found is reflecting on what you’re doing. Take time to shortly discus how a meeting, brainstorm, pair programming session went. Look back on iterations or longer periods together with customer. (e.g. using retrospectives)
After writing this post, I shortly googled for similar stories. I found that the source of this anecdote is Steve Corey’s book The 7 Habits of Highly Effective People. This book has been put on my list of books I want to read.
Here’s a post on mind mapping. A few months ago, I pulled this undervalued tool from the bottom of my toolbox and it has proven it´s use.
About five years ago, while I was still studying, I learned about mind mapping. A guy named Jan-Willem van den Brandhof, the owner of brainstudio and writer of this interesting book, gave a workshop on how to use your brain more effectively. I learned that mind mapping is a technique for capturing information. Originally invented by Tony Buzan. By stimulating both sides of your brain, mind mapping helps you to remember better.
During the workshop, these ‘rules’ of mind mapping were teached:
In a mind map these rules might look like the following image:
One thing I could not find on the internet or in the book is the addition of the date and your authograph to your map. I liked this subtle twist, because it makes your map a personal piece of art.
During the workshop mindmapping fascinated me, but I concluded it was not of practical use to me and continued studying algorithms and data structures.
A few months ago I started mindmapping to create meeting minutes. Why? I can’t remember. What happend? I found out I could capture meetings better, while stil participating in the conversation. Second, I remembered more of what was said during the meeting. As it proved it’s worth, I started using mind maps for other purposes. Such as:
The maps helped me in capturing my thoughts during these brainstorms. I also found that mind maps help me ‘steer’ my thoughts. Going up or down a branch helps keeping focus or switching to a slightly different context.
For those of you who want to try mind mapping, you only need the following tools:
For those in search of software: xmind and mindmanager are two. I use xmind to capture some (non-readable) mindmaps for distribution and it works quite intuitive. But, I would not recommend using the computer while brainstorming, nothing beats ‘going analog’.
While writing this post, I looked back at what I remembered about mind mapping and remarkably it was almost everything. I started using the technique right out of the box. At first I used one color, mainly out of convenience. But I am introducing multicolor now. There is one thing I do ‘wrong’. I am not putting words on the lines. Somehow I created a method where I draw roots ending up in words, which again spawn roots. This has worked for me and I concluded it is what makes those maps unique.
My bag now has as set of stabilo´s and whenever a suitable moment occurs I start mindmapping. The next map, I will try the official way to get a feel of the difference. Another thing I would like to explore is using mind maps during team retrospectives. During the retrospective, different maps with specific topics are passed through to team members and people add their thoughts to eachother’s maps.
Hello world! My name is Maarten Dekkers and I am starting a blog.
Why?
Yes, I know, it will be the trillionth out there, but why not? I like exploring new stuff to learn from it. This is my next exploration.
What will you be writing about?
Everything that I find worthwhile mentioning. Wait! Don’t leave yet. Let me be a bit more specific:
What does Ramenta mean?
Ramenta is my nickname and it’s an anagram of Maarten. This nick was created in 2004, when I searched for a unique name for my personal domain. For the Dutch readers: Another anagram of my name is ‘Starende Makker’.
What’s this strange ‘Lorum ipsum’ post?
Lorem ipsum is a dummy text used in printing and typesetting industry. (www.lipsum.com) During development we sometimes use it as default text. This prevents text ending up in software, that afterwards appears to be embarrassing. The post filled with some lorem ipsum paragraphs will help me creating the design for this blog.
Why do you need my help?
This blog started with installing wordpress and it created this nice default theme for me. But I want my blog to have a personal touch. Probably I can download one of the million other themes already available. But I want to create one of my own.
My question to you is: What are blog’s whose design you really like? Personally, I like simple, elegant, easy to use designs. For now I will use the default theme and start exploring how to create/modify my own.
Note: This doesn’t necessarily mean a blog you like to read. I’m also not asking you to make a design for me.