mikkeman.nl

“Better is worse than good enough” (or the Dutch equivalent “Beter is slechter dan goed genoeg”) has been my tagline for quite some time. I put it below emails, use it on this blog and anywhere else where it seems applicable. BTW, I don’t deserve the credits, I first heard this quote from professor emeritus Nielen (not sure if he is the authentic source either).

Many people are confused when they read it and ask me what it means. How can better be worse? Better is better, right? And certainly better than good enough, right? Wrong.

The statement reflects pragmatism. Simplicity. Or, as Einstein put it: “Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -and a lot of courage- to move in the opposite direction.”

It feels counter intuitive. We always want to make things better. But think of this: a better solution might be, uhm…, better, but it has at least three major disadvantages:

1. It takes more time to make things better – we don’t have this time
2. It costs more money to make things better – we don’t have the money
3. It has a higher probability on errors – which cost time and money to fix

In software development, we tend to “gold plate” solutions and include all kinds of bells and whistles that will “certainly blow away our customer”. Will this customer really be delighted by those bells and whistles if it means that his project is over budget and too late?

The trick is to hit the sweet spot between “too little” and “too much”. The only way to know that spot is to get frequent feedback -early and often- from your customer. This is one of the core principles of agile software development: close collaboration between development and customers. Scrum implements this principle with the Product Owner role, collaborating closely with the team, delivering software in short Sprints, ending with a Sprint Review of working software.

Now you know what I mean with “better is worse than good enough”. Try it for yourself!

Photo taken from wallyg under Creative Commons license.

This post is for people running a private Samba server, wishing it was securely accessible over the Internet. Stop reading if you don’t know what Samba or SSH means.

Imagine the following situation: at work, school or a client site, you insert your USB stick, check your local hard drive and search your Gmail account to find out that the one file you were looking for is not there. You probably left it at home. Damn!

Sounds familiar? It does happen to me frequently.

A solution is to have access over the Internet to your private Samba server. No more worrying that you didn’t take a particular file with you, just access it from anywhere you like. But you also want that access to be secure. Can it be done? Yes.

What do you need?

• A server running Samba that also provides SSH access from the internet
• Windows XP on the client
• PuTTY on the client

read more »

Last Thursday we had the last planning meeting of this year. In three weeks time, we will deliver the last release of 2009, ready to be put in production on January 1st, 2010 (this 6 week gap is something for another blog).

It feels kind of awkward, to be planning the final set of user stories. Is this really everything? Can we really miss all that other stuff on the product backlog? Everybody is quite confident that we produced good results.

Nonetheless there are some oddities. While things are being tested continuously, any issues uncovered normally entered the product backlog. In this last iteration, if an issue turns out to be more important than stories already planned, we (team + product owner) agreed to reprioritize during the sprint.

This also means that the team is now even more disciplined about how many user stories to develop concurrently, because we don’t want the PO to drop a user story we’ve just started working on.

But… as the number of user stories decreases and the PO is allowed to reprioritize all work that hasn’t started yet, we might as well say that we’re doing Kanban!

As I said in my previous post, “Kanban, Lean and Scrum Are Not Religions…”, it depends on your situation what tool suits you best. For almost a year, we used Scrum. For the end game, Kanban seems like a better tool. Just do what works.