Blog-tagged – truth or dare for bloggers

There is a game of Blog-tagging going on, which works like a kind of chain-letter.

The idea is that the person (owning a blog) that gets tagged, shares five little-known facts about him or herself and tagges five other persons (owners of blogs).

I got tagged by former collegues Raimond Brookman, who shared five secrets of which I new three (he’s tall, plays squash and loves meat) and Jeroen Leenarts (of which I knew about the Apple, but was surprised about the alcohol).

So here are my five little known facts:

1. At the age of 18, I was homeless for two months in Utrecht, Netherlands. In that period I slept in a shopping centre and in the weekends worked in a bar that opened at 01:00 and close at 06:00. 

2. One of the jobs I had before entering Computer Science was wedding photographer.

3. I ordered a new car, a Ford S-Max.

4. I’m married with Betty, have three daughters (Lieke 16,Ellen 14, Manon 12) and a dog (Sieta)

5. Harry is my usual name, but my original name is Harm, and I’m having my aniversary on Christmas Day.

I would like to blog-tag the following bloggers:

1. Scott Sehlhorst 

2. Marcus Ting-A-Kee

3. Micahel Hunter (The Braidy Tester)

4. Stephan Okhuijsen

5. Dilbert


Comments (1)

Security in Use Cases

Many efforts are being made to integrate security into software and software development. I lately read several interesting posts about the subject, two of them from Gunnar Peterson

Gunnar Peterson

In an IEEE Security & Privacy Journal he co-wrote an article on Misuse Cases with John Steven on Defining Misuse in the Development Process.

Here’s in short what is the core idea:

Use Cases vs Misuse Cases

I remembered having seen the idea before, as Richard Claassens, a former collegue and Architect at InfoSupport showed some examples that came from the original ideas behind Misuse Cases came from Guttorm Sindre and Andreas Opdahl.

Here’s a nice example:

Misuse Case diagram

Leave a Comment

Early overtime == later project completion

Crossing the desertJohanna Rothman wrote about avoiding the “Crossing the desert syndrome” some years ago.

“A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome”

Recently she gave advice on how to recover from the syndrome.

At Tyner Blain, Scott gives advice on how to prevent from hitting the syndrome: 

  • Improved estimation of tasks
  • Realistic effort allocation
  • Writing verifiable requirements
  • Managing smaller work chunks
  • Feedback into the estimation cycle
  • Better communication of release content

As I read his advice I thought: “yes I agree that’s good advice, but somehow good advice is seldomly followed”.

 BTW: Patrick van Lee, a relative from my wife,  rides the Dakar race on an Aprilia motorbike

Comments (1)

Outsourcing: from assembly line to extended team


Recently I became interested in outsourcing. Partly because we addressed the subject in reaching CMMI level 2, partly because I recently read the book “The World is Flat” in which “Thomas L. Friedman believes the world is flat in the sense that the competitive playing fields between industrial and emerging market countries are leveling. Friedman recounts many examples in which companies in India and China are becoming part of large global complex supply chains that extend across oceans …” (from Wikipedia).

In Managing outsourced teams. Balancing innovation with predictability. two different approaches to create a remote engineering organization:

  • Assembly line (requirements are sent overseas to be built there as specified; prerequisite is that the requirements are really good and stable)
  • Extended team (requirements are sent overseas and interpreted, a design or prototype will be created overseas and approved by the main office, emphasizing on collaboration).

Based on their experience the authors suggest that the best way to go about this problem is to start on the Assembly line “mode” and to transition to the “Extended team” mode as soon as you feel comfortable to do so.

hidden costsI think that’s a sound suggestion! Beware that on both approaches, there are lots of hidden costs when outsourcing.  

Leave a Comment

Visual Studio 2005: See the difference

Microsoft took some effort to promote Visual Studio 2005.

Take a look at the 400+ differences, like:

144 Better ASP.NET Source Code Editing – Edit faster, eat better

195 Bug list – Automated debugging. Keeps code tidy. (one of Erno‘s favourites)

212 Operator overloading – Goodbuy struggle, Hello joy

The even made a game about spotting the differences

Leave a Comment

Use Cases to make a better has recently been changed. Microsoft did a lot of research to make it easier to find what you look for at

On the about page, some questions about the changes are answered.

One of the reasons the new page is assumed to be better is that “We based our design on data of the most common tasks, products, and services that people come to our site for, and then we validated and improved the design during months of customer testing.”

To me, as seasoned requirements specifier, this seems to be an obvious way to do your analysis and design, but  when teaching classes and when coaching collegues, I often find they don’t take the time to find out the most common “Use Cases” for the system they are building.  Nice to see that Use Cases seem to be working at Microsoft.

Leave a Comment

how – not – to make a process work for you

Anti patternGary Pollice (“I’m the one with the head”) publised an interesting article on anti-patterns for process adoption in the Rational Edge.

At Getronics in the Netherlands we’re in the middle of adopting our process. We first documented our RUP-based “Getronics Development Process” using IBM Rational Method Composer. We documented some additions and our Getronics best practices and were appraised at CMMI level 2 last December. Now we’re rolling out the process and are facing two views on the way to go ahead.

One group wants to keep moving and go for CMMI level 3 right on. An other group wants to first take all our energy to get level 2 rolled out first, before moving on.

Reading the article from Gary, I would say we’re hitting the “Take all the medicine at once” anti-pattern if we try to move on to level 3 right away. In short, the antipattern says process changes take time, so it is better not to do everything all at once, but to do small process improvements at a time. For our situation, that would mean it is wise to roll out level 2 first!

BookMore anti-patterns can be found in Organizational Patterns of Agile Software Development. Gary Pollice did a review of the book, another review is at

Leave a Comment

« Newer Posts · Older Posts »