Codename Nemo 0.1 alpha released

We've finally released an alpha version of our file manager project!



This has been a long way. The idea has been the same throughout the project, to focus on the aspects of documents that people actually remember instead of forcing a hierarchical tree down their throat.

Believe it or not, a lot of novices find it difficult to understand the hierarchical folder structure, and it's not particularly easy to navigate or keep in order for most computer literates either. People have trouble remembering what folder they put things in - and they would rather not put things into folders if they can avoid it.

This has been known for a very long time. We're building on research from the 80s here.

The big question is how you design a GUI that makes it possible to find the files again without a hierarchy. There's been a lot of attempts on this. Recently, people have been using pure text search - but while it can help, it's not a panacea. It's not always easy to remember something precise enough to put into the seach bar.

There's also been a lot of experiments with 3d spatial systems that mimic the physical world, usually with a high bling-bling factor. They look funny, but in my opinion they're never going to work because a) cleaning up in the physical world is really painful and something most people tend to avoid and b) the physical world scales really bad. Sure it's easy to find something on your desk if you only have 10 documents on it. But what if you have 1000?

So what do you do? We started from something that looked completely different from what this alpha release looks like and went through a couple of iterations before we arrived at what we have now.

There are lots of problems in this alpha release, but I personally think the basics are about right now. Is it usable? I think so. You can't select files or delete them, or even rename them because we haven't coded a proper custom widget for it yet (like e.g. in Nautilus). Must of the automatic stuff that's supposed to be smart is really pretty dumb because it hasn't been refined yet.

But you can get an overview of your files, organize them and find them again. And that's what it is all about.

Adding quote marks with Django

I've posted my first Django snippet on djangosnippets.org. It's a template filter for adding quotes around a piece of text. It's clever enough to take paragraph tags into account.

Debugging

I've been thinking about debugging lately. In my humble opinion, there are four phases in the art of debugging.

The first phase, which I think of as the debug prevention phase is where you proactively do something to prevent silly bugs from happening.

The thing is that debugging is time-consuming. Not only because you have to find the bugs, but also because it disturbs the flow. Silly bugs are like faulty brakes on a bicycle. It's neither fun or productive to push and push to get up to speed just to find yourself hanging over the handlebars at a sudden halt.

So it's worthwhile to do something to avoid obvious sources of bugs.

Here's an example of an obvious source that I recently encountered (apologies to the source): you have a model class with a certain state which can change on its own while also being changed in the user interface by the user. One way to approach this is to code the model and user interface separately, each with its own state, then add a bit of glue code to synchronize the two.

The (obvious) problem is that the two copies of the states can get out of sync, in which case you're toasted. It's also pretty confusing - when you ask for the real state, the master state so to speak, where do you ask? The model or the UI? So avoid the copy in the UI, even if it's less convenient to have to go ask the model all the time.

Of course, obvious sources of bugs are probably not obvious unless you spend some time reflecting on what you're doing. Here's a simple rule of thumb: If something is so confusing to think about that you can't immediately make head or tails of it, then it's probably worthwhile spending some time refactoring it because otherwise it's likely to become a source of bugs. Sometimes it's just a matter of renaming variables and functions.

The second phase is testing. This is where you find the bugs. The relation to debugging is that you should test and never assume that things are working just because the compiler/interpreter/whatever ate it. Untested code is an obvious source of bugs and it's always better to fix the bugs before you've embarassed yourself by shipping them. Debugging in the open is not fun. It's also much easier to find the bugs if you test early.

The third phase is the trial-and-error phase. This is the initial reaction most people have when something stops working: What, it worked before, let me just try this, then it'll probably work again. Repeat.

What's important in this phase is to leave it early if the first couple of tries don't work out. Trial and error is time-consuming and mentally draining because it puts you through lots of frustrating failures with no clear reward. Don't get stuck.

Instead consider proceeding to phase four which is the observation-thinking cycle. Here the goal is not to fix the problem, but to understand what's going on. Think of yourself as the analyzing surgeon who's on a mission to make the smallest possible cut, not the rampant safari hunter with the over-size elephant gun.

How do you understand your program? By running it, either in a debugger or with print statements sprinkled so you can see why the code is failing. You start at the innermost level, then gradually trace your way through the call stack.

The idea is not to trust anything you see. It's always a bad idea to assume something is working before you have printed the result and verified it in the actual faulty run. For instance, it might be a good idea to really start at the innermost level even though there's nothing exciting going on there. I've spent countless hours trying to understand why something obviously correct wasn't working just to find out that the code I was looking at wasn't actually the code running. Maybe you've forgotten to save the file. Or upload it. Or recompile. Or maybe it's running another, similar function you've forgotten about. Or maybe it suddenly crashed because of something seemingly unrelated. A print statement can tell you the truth.

You observe (real output, not source code) and you think, add more debug code, and observe and think. When you're done, you know what the program, your little creation, is doing. That's a nice, rewarding feeling. You're in control. And it makes the kind of story you can tell your (geeky) friends: I had this really annoying bug, and I traced it through ..., and finally I had it nailed!

Sometimes it's difficult to proceed to phase four because the debugging environment, frankly, is not up to the task. In which case you'd better start working on the debugging environment rather than building up frustration when the bugs begin to manifest themselves. So little is needed - if you can get printf-like output and short compile-run cycles, then you're good to go.

Peopleware

I finished reading Peopleware: Productive Projects and Teams. It's about the human factor of conducting projects. Which according to the book completely overshadows any other aspects of the project, even though it's often ignored completely.

The way the book is written it's addressing project managers. But don't let that fool you. If you're somehow involved in a software project, you're also involved in the management of it. If you're not, there's something wrong - read the book to find out why.

I think the main message of the book is that you should focus on keeping the people involved in a project happy to make the productive.

Make their work fun, go to great lengths to ensure they can work together well as a team, stay out of decision making that others are in a better position to do in spite of what hierarchy suggests and avoid interrupting everyone all the time.

In doing so, you're likely to have increased their productivity by an order of magnitude more than any Methodology (as they put it) can give you. The reason is that people are not machines. If you expect them to be and make them feel that way, and this is easier to do than you might think if you come from a software background where it's all about the logics, then it shifts from high gears to low gears, the magical stuff that makes a design or a program uncover itself from nothing just by the help of human mind.

There a lot of interesting tidbits in the book too. For example, it's often postulated that you need a deadline to make people work efficiently. So okay, people are not machines, they're much worse, they need a bit of whipping to make them work hard. The book cites a study which found that people are almost twice as productive on projects without a deadline compared to projects where the project manager sets one.

Another example is that people tend to react to change in unpredictable ways. For instance, if you do something different from what you use to do, you might be more productive, not necessarily because the new way is better than the old, but simply because you expect it to be better (I guess this is the Placebo effect) or because it's new and exciting and you're generally more productive when you're excited. The authors call the phenomenon the Hawthorne effect after an experiment with illumination in a factory. Increase the lighting and people are more productive, decrease the lighting and people are also more productive.

Anyway, if you're somehow involved in software projects, or any other kind of mind-worker projects for that matter, I recommend you read this book. You won't regret it. It taught me more about my work than any other book I've ever read.

Torturing prisoners

I unsubscribed last Friday.

I can't believe some of the stories you hear. What happened to the Geneva Conventions? What happened to treating other people, including your enemies, with respect? What happened to being decent people?