- Details
"No parking" on a parking lot? Do I know that sign? And if not here, where?
A lot of fun, a fair. But in Maassluis the owners of the attractions park their cars on the parking lot at trainstation Maassluis West. And where do the regular train travelers need to park?
Also interesting is that it is apparently accepted to make up a "traffic sign" that keeps out regular traffic users from a usually accessible part of the public road. That may be fun to try at home....
- Details
Quality of software workshop at the fifth NBIC conference. The topic is introduced by Machiel Jansen from SARA. #nbic5
- Details
NBIC
hackathon just started. What can we interconnect? #nbic #hackathon #work
- Details
A small bug in the twitter interface, just after the formal "retweet" feature was introduced. After I retweeted this message it said "retweeted by you and 7 others", but "you" showed a weirdly different twitter account.... #oops #twitter
- Details
I realized that over the course of the years I have been visiting several quite different areas of the globe. This made me decide to make a special cross section of the pictures that I have taken over the years: a set with as special property that any pair of pictures selected from the set are always taken at more than 1000 km distance from each other. The result: 21 pictures, representing 21 completely separate circles of 500 km radius, about 3% of the earth's surface. I still have a long way to go!
- Details
Imagine a mechanical workshop. You come with a problem that they will solve. What do you expect? You expect to work together with them, roughly in the following five-step procedure:
- Specify. You will describe the problem in the form of a functional specification
- Design. They will make a drawing
- Pieces. They (possibly multiple people in parallel) will use the design to select and manufacture pieces
- Product. They will weld the pieces together into the tool you need
- Test. You test it, and it may require minor adjustments
Now imagine a software workshop. You come with a problem that they will solve. What do you expect?
- Specify. You will describe the problem in the form of a functional specification
- Product. They will make the software tool
- Test. You alpha test, they fix, you beta test, they fix. Repeat until satisfactory
How come this list contains only three instead of five steps? And why is the last step always causing so much pain? Could this difference be the origin of why so many software products fail? What is the real difference between software and hardware development?
Rather than trying to solve the software problem at once, first imagine a hardware workshop that works like this:
- Specify. You will describe the problem in the form of a functional specification
- Product. They will weld materials together into a tool
- Test. You test, they fix, you test again, they fix. Repeat until satisfactory
How likely would it be that this procedure is faster than the five step procedure? How obvious is it which pieces need to be welded together? Will this allow multiple people to work together on the product? And how much work is the testing for you? How much waste is produced in the process? You would not accept this kind of quackery! And my point: you should not accept it from a software workshop either.
A good software workshop would use the same five steps the good mechanical workshop uses:
- Specify. You will describe the problem in the form of a functional specification
- Design. They will make a (modular) design
- Pieces. They (possibly multiple programmers in parallel) will use the design to build and select software modulesÂ
- Product. They will use the modules to build the software you need
- Test. You test it, and it may require minor adjustments
Investment in a design will result in a solution that will truly solve your stated problem, and not require endless iterations to get right. It may look like a slow solution, but that is deception: you will actually get a result that gets you where you want to be, also when you have new additional requirements in the future.
I'd like to thank a former colleague at Bruker AXS that gave me this nice comparison. I know he wishes to remain anonymous on the 'net. Image credits: Dystopos on Flickr.
- Details
De uithof scate rink. Cooling system failed…. #oops #nh3
- Details
After every radical change in an organization, there is a need for a phase of quiet thoughtful improvements. Expecting miracles from huge corporate reorganizations is a fallacy that leads to reorganization upon reorganization potentially resulting in complete destruction of the organization.
Have you ever played a game of Pac-man? It is a simple game where you control a little eater eating dots on the screen, while ghosts are chasing you. The game is an excellent mirror of business life in a changing environment:
- In Pac-man, you are trying to improve your health at every step by eating a dot and staying out of the way of the ghosts.
- In business life, you are making small changes to your products and procedures to sell more and stay out of the way of your competitors.
There is a further analogy:
- In Pac-man, sometimes things get stuck. Ghosts are closing in from all sides, and there is no escape. At such a point, you can use the teleport: a panic key that takes you to a random spot in the scene in an instant.
- In business life, sometimes things get stuck. Competitors are closing in and it seems there is no way out. At such a point the CEO will call (often quickly without consulting all those that are involved) for a radical reorganization.
In business there is an important lesson we can learn from the teleport feature in Pac-man: A teleport is far from a guaranteed save! It can bring you into a very dangerous situation. The goal of the teleport is not an immediate improvement in the flow of the game, it is to escape from a hopelessly stuck situation, from impending disaster. Directly after a teleport, you have to act and make steps to regain control. Similarly, in business a radical reorganization will rarely take you to a better situation immediately. A reorganization is meant to shake up the bowl and escape from a hopelessly stuck situation (often invisible to many of the employees). After the relatively thoughtless jump that has to be executed quickly to avoid an immediate game over, the organization will need to go into a thoughtful phase in which small improvements are made to optimize the situation.
If you realize that a reorganization has not brought you immediate gains, try to refrain from making further reorganizations. Instead, look for opportunities for small changes, and give it some time.
- Details
If you are not getting any user feedback for your software, there are two possible reasons.
- It is bad. Nobody uses it.
- It is good. Everyone is happy.
If this happens to you, think back. Did you ever get any feedback before? How did you react?
- Did you listen to your users and fix their problems?
- Did you teach your users your way to use your software?
By answering these two questions you can figure out for yourself why you no longer get feedback. If you listened, and the stream of questions stopped, this probably means the users are now happy. If you attempted to correct their usage, most likely nobody uses it any more.
You did remember to include your contact details, did you?
- Details
An array of speakers lined up for their lightning talks at the Dutch Semantic Web Meetup #dswm #conference