Inductive Bias

After summarising some strategies for not loosing track of tasks, meetings and conferences in the last post, this one is going to focus on the retrospect on achievements. If at some point in time you have asked yourself “Where the hack did time go to?” - maybe after two busy weeks of work this article might have a few techniques for you.

Usually when that happens to me it’s either a sign that I’ve been on vacation (where that is totally fine) or that too many different, sometimes small but numerous tasks have sneaked into my schedule.

Together with Thilo I have found a few techniques helpful in dealing with these kind of problems. The goals in applying them (at least for me) have been:

• Configure the planned work load to a manageable amount.
• Make transparent and trackable (to oneself and others) which and how many tasks have been finished.
• Track over time any changes in number of tasks accomplished per time slot.

After hearing about Scrum and its way of planning tasks I thought about using it not only for software development but for task planning in general. Scrum comprises some techniques that help achieving the goals described above:

1. In Scrum, development is split into sprints: Iterations of focussed software development that are confined to a fixed length. Each sprint is filled up with tasks. The number of tasks put into one sprint is defined by the so-called velocity of the team.
2. Tasks are ordered by priority by the product owner. Priority here is influenced by factors like risk (riskier tasks should be attacked earlier than safe ones), ROI (those tasks that promise to increase ROI most should of course be done and launched first) and a few more. After priorisation, tasks are estimated in order - that way those tasks most important to the product owner are guaranteed to have an estimated complexity defined even if there was not enough time to estimate all items.
3. Complexity here does not mean “amount of time to implement a feature” - it’s more like how much time do we need, how much communication overhead is involved, how complex is the feature. A workable way to come up with reasonably sensible numbers is to chose one base item, assing complexity of one to it and estimate all coming items in terms of “is as complex as the base item”, “has double the complexity” - and so on - according to the fibonacci series. Fibonacci is well suited for that task as do not increase linearly - similarly humans are better at estimating small things (be it distances or complexities). As soon as items get too big, estimation also tends to be way off the real number.
4. To come up with a reasonable estimate of what can be done in any week, I usually just look back to past weeks and use that as an estimate. That technique is close enough to the real number to be a working approach.

To track what got done during the past week, we use a whiteboard as Scrum Board. Putting tasks into the known categories of todo, checked out and done. That way when resetting the board after one week and adding tasks for the following week it is pretty obvious which actions ate up most of the time. The amount of work that goes onto the board is restricted to not be larger than what got accomplished during the past week.

So what goes onto the whiteboard? Basically anything that we cannot track as working hours: The Hadoop Get Together can be found just next to doing the laundry. Writing and sending out the long deferred e-mail is put right next to going out for dinner with potential sponsors for free software courses at university.

Now that weekly time tracking is set-up - is there a way to also come up with a nice longer term measure? Turns out, there are actually three:

First and most obviously the whiteboard itself provides an easy measure: By tracking weekly velocity and plotting that against time it is easy to identify weeks with more or less freetime. As a second source of information a quick look into ones calendar quickly shows how many meetings and conferences one attended over the course of a year. Last but not least it helps to track talks given on a separate webpage.

It helps to look back from time to time: To evaluate the benefit of the respective activities, to not loose track of the tasks accomplished, to prioritise and maybe re-order stuff on the ToDo list. Would be great if you’d share some of your techniques of tracking and tracing time and tasks - either in the comments or as a separate blog post.

Freetime, Hacking, Scrum Scrum, Time management

the evening after FrOSCon - that is on August 22nd 2010 at 7:30p.m. CEST - a combined “FSFE Fellowship meetup/ Apache dinner*” takes place in Tigges in Düsseldorf (Brunnenstraße 1, at Bilker S-Bahnhof). Given it doesn’t rain, we’ll be sitting outside.

Would be great to meet you there for tasty food, interesting discussions on Apache in general, as well as projects like Lucene, Hadoop or Tomcat in particular. Anyone interested in either the FSFE or Apache is welcome to join us.

One personal request: Somehow, Rainer (Kersten, FSFE) talked me into preparing a talk on what the ASF is all about - would be really great to have more people around share their experience.

See you in Düsseldorf

Free Software, Freetime, General, Software Foundation Dinner, DUS, FSFE, Software Foundation

This evening at Volkspark Friedrichshain, Café Schoenbrunn the next NoSQL summer Berlin (organised by Tim Lossen) is meeting to discuss the paper on Amazon’s Dynamo “Dynamo: Amazon’s Highly Available Key-value Store”. The group is planning to meet at 19:30 for some beer and discussions on the publication.

Freetime, Science Berlin, NOSQL

In the last post I promised to share some more information on techniques I came across and found useful under an increasing work load. Instead of taking a close look at my professional calendar I decided to use my private one as an example - first because spare time is even more precious then working hours, simply because there is so few of it and secondly because I am free to publicly scrutinize not only the methods for keeping it in good shape but also the entries in it.

I am planning to split the article in four pieces as follows as keeping all information in one article would lead to a text longer then I could possibly expect to be read from beginning to end:

Part 1: Traveling minds - how to stay focussed in an always-on community. Part 2: Tracking tasks, or: Where the hack did my time go to last week? Part 3: A polite way to say no - and why there are times when it doesn’t work. Part 4: Constant evaluation and improvement: Finding sources for feedback. Part 5: A final word on vacation.

Several years ago, I had no problem with tasks like going out reading a book for hours, working on code for hours, answering mails only from time to time, thinking about one particular problem for days. As the number of projects and tasks grew, these tasks became increasingly hard to accomplish: Writing code, my mind would wander off to the mailing list; when reviewing patches my mind would start actually thinking about that one implementation that was still lingering on my hard disk.

There are a few techniques for getting back to that state of thinking about just one thing at a time. One article I found very insightful was an essay by Paul Graham. He gave a pretty good analysis of thoughts that can bind your attention and draw them away from what should actually be the thing you are thinking about. According to his analysis a pretty reliable way to discover ideas that steal your attention is to observe what thoughts your mind wanders to when you are taking a shower (I would add cycling to work here, basically anything that lets your mind free to dream and think): If it is not in line with what you would like to think about, it might be a good time to think about the need to change.

There are a few ways to force your mind to stay “on-topic”. Some very easy ones are explained in a recent blog post on attention span (Thanks to Thilo for the link):

• Organising your virtual desktops such that applications are sorted according to tasks (one for communication, one for coding project x, another one for working on project y) helps to switch off distraction that would otherwise hide in plain sight. Who wants to work on code if TweetDeck is blinking at you next to your editor? In contrast to the original author I would not go so far to switch off multiple monitors: Its great to have your editor, some terminals, documentation in the browser open all at the same time in one workspace. However I do try to keep everything that has do with communication separate from coding etc.
• Train to work for longer and longer periods of time on one task and one task only: The world does not fall apart, if people have to wait for an answer to your mail for longer than 30min - at least they’ll get used to it. You do not need to take your phone to meetings: If anything is starting to melt down there will be people who know where you are and who will drag you out of the meeting room in no time. Anything else can well wait for another 60min.
• When working with tabbed browsing: Don’t open more tabs then you can easily scan. You won’t read those interesting blog post you found four weeks ago anyway. In modern browsers it is possible to detach tabs. That way you can follow the first hint of keeping even the web pages sorted on desktops according to activity: You do not need your time tracking application next to your editor. Having only documentation and testing application open there does help.
• Keep your environment friendly and supportive. Who has ever shared an office (or a lecture at university back when I was a student) with me knows that close to my desk the probability of finding sweets, cookies, drinks and snacks approaches one. Being hungry when trying to fix a bug does not help, believe me.

One additional trick that helps staying just focussed enough for debugging complex problems is to make use of systematic debugging by Andreas Zeller (also explained in Zen and the Art of Motorcycle Maintenance). The trick is to explicitly track you thoughts on paper: Write down your hypothesis of what causes the problem. Then identify an experiment to test the hypothesis - you should know how to use your debugger, when to use print statements, which unit tests to write and when to simply take a very close look at the code and potentially make it simpler for that. Only when your experiment confirms that you have found the cause of the problem you really have identified what you need to fix.

There are a few other techniques for getting things off of your head that are just there to distract you: If you ever have read the book “Getting things done” or seen the Inbox zero presentations you may already have an idea of what I am hinting at.

By now I have a calendar application that works like a charm: It reminds me of meetings ahead of time, it warns me in case of conflicts, it accepts notes, it has an amazing life span of one year and is always available (provided I do not forget it at home):

- got mine here That’s for organising meetings, going to conferences, getting articles done in time and not forgetting about family birthdays.

For week to week planning we tend to use Scrum including a scrum board. However that is not only for planning as anyone using Scrum may have expected already.

For my inbox the rule is to filter any mailing list into its own folder. Second rule is to keep the number of messages in my inbox to something that fits into a window with less than 15 lines: Anything I need for further reference (conference instructions, contacts, addresses that did not yet go into my little blue book, phone numbers not yet stored in my mobile phone) goes into its own folder. Anything that needs a reply is not allowed to stay in the inbox for longer than half a week. For larger projects mail gets sorted into their own project folders. Anything else simply goes to an archive: There are search indexes available, even Linux supports desktop search, search is even integrated in most mail clients. Oh and did I mention that I managed to search for one specific mail for an hour just recently, though it was filed into its own perfectly logical folder - simply because I had forgotten which folder it was?

To get rid of things I have to do “some time in the near future but not now” I keep a list in my notebook - just so my mind knows the note is there for me to review and it knows I don’t forget about it. So to some extend my notebook is my personal swap space. One thing I learnt at Google was to not use loose paper for these kinds of notes - a bound book is way better in that it keeps all notes in one place. In addition you do not get into danger of throwing notes away too early or mis-place them.

The only thing missing is a real product backlog that keeps track of larger things to do and projects to accomplish - something like “I really do need to find a weekend to drive these >250km north to the eastbaltic sea (Thanks to Astro for pointing out the typo to me - hey, that means there is at least one guy who actually did read that blog post from beginning to end - wow!) and relax”

Free Software, Freetime, Hacking, Software Foundation Getting things done, Scrum

Probably not too unusual for people working on free software mostly (though no longer exclusively) in their spare time, the number of items that appear in my private calendar have increased steadily in the past months and years:

• Every three months I am organising the Apache Hadoop Get Together in Berlin.
• I have been asked (and accepted the offer) to publish articles on Hadoop and Lucene in magazines.
• There are various conferences I attend - either as speaker or simply as participant: FOSDEM, Froscon, Apache Con NA, Devoxx, Chemnitzer Linuxtag - to name just a few.
• For Berlin Buzzwords I did get quite a bit of time for organisation, still some issues leaked over to what others would call free time.
• I am mentoring one of Mahout’s GSoC students which is a lot of fun.
• At least I try to spend as much time as possible on the Mahout mailing lists keeping up with what is developed and discussed there.

There are various techniques to cope with increased work load and still find enough time to relax. Some of them involve simply remembering what to do at the right time, some involve prioritization, others deal with measuring and planning what to do. In this tiny series I’ll explain the techniques I employ - or at least try to - in the hope of getting your feedback, and comments on how to improve the system. After all, the most important task is to constantly improve ones own processes.

Freetime, Hacking, Scrum Free Software, Getting things done, Scrum, Software Foundation

During the past two weeks my teddy was on vacation. As destination he chose to fly to Portugal. One day was reserved for a visit to Lisboa, the capital city of the country. He also took a few really nice pictures there:

On his return, he was no longer alone. Seems like he found a cute little portugese girl friend:



In addition he brought the following image. However he promised that he was not in California, but explained that the bridge actually does exist in Lisboa, being constructed by the same company according to the same blue prints that already were used for Golden Gate bridge:

Freetime Lisboa, teddy, vacation

… for the next two weeks: I’ll be on vacation with strict internet interdiction. Will be a tourist exploring beaches and maybe a few hiking tracks in the next few days, so don’t expect to read anything here apart from what was scheduled already

Freetime vacation

First thing to do after getting up: Go to the kitchen and switch on the coffee machine. However, one random Sunday morning that caused the fuse for exactly this kitchen to go off. After fixing that we turned on the coffee machine again - trying to finally get a first cup. All worked well until having a closer look at what the machine produced as coffee: It was cold!

We initially got the machine from Giuseppetti - a vendor in Berlin. Though it was to late to get it fixed on warranty we still took the thing over to his shop the following week. What happened than was amazing to see for us:

The mechanics unscrewed the machine, started examining it immediately. Knowing we had bought it there, the owner gave both of us a cup of coffee. Long before I had finished mine the fixed machine was brought back to us - a fuse in it had gone off as well.

So after less than half an hour we got our working coffee machine back w/o being charged for the repair. Next morning was way better than the previous Sunday morning.

Freetime coffee, service

Like most software developers I like tasks that involve solving more or less complex problems analytically. Most developers I know love puzzles - either those that involve dis-entangling metal rings, or those involving putting wooden pieces back into order, or even solving Rubik’s cube:

Working on the schedule for Berlin Buzzwords, I noticed that coming up with a good schedule actually has a lot more in common with solving puzzles that one is usually aware of: First of all talks on similar or related topics should not take place at the same time. Presentations should be grouped according to common topics so attendees don’t have to switch room after each and every talk. In addition some speakers have a tight schedule themselves and can only be at the conference for a day.

It gets even more interesting if after having put up a draft of the initial schedule you start filling the gaps, publishing those talks that were confirmed later than others or could be accepted only after freeing a spot somewhere else.

I spent the past few day re-arranging the Berlin Buzzwords schedule a bit. I added Christophe’s talk on Apache Hadoop from an industry perspective. After adding it, I had 45min left in the NoSQL track - on the other hand there was a speaker from the Lucene community that we very much liked to have in. So off I went, sorting and shifting around until finally the Lucene talk ended up in the Lucene track and a Hadoop talk that was formerly there ended up in the Apache Hadoop track, resulting in one NoSQL talk from the Apache Hadoop track moving over to the NoSQL track…

To cut a long story short: The schedule is final now - unless changes need to be made last minute.

Berlin Buzzwords, Freetime Berlin Buzzwords, puzzles, schedule

I love taking fotos, like being outdoors and like animals. Living in a large city, it is not exactly easy to get in touch with donkeys or sheep. A very simple way to combine all three preferences here is to visit Tierpark Berlin. Being larger than your average zoo, most bawns are rather roomy with lots space outside and inside.

Little more than one year ago I received a great birthday present from Thilo: It is possible to purchase a one year ticket for that park. Since we’ve been there pretty often. In spring when most animal babies are born, in summer to escape heat in town, in winter when all paths are white of snow.

One attraction we usually do not want to miss are the pelicans (Thanks to p_h_o_t_o_m_i_c who took the picture below):

If you are wondering “What’s that thing hanging ’round her neck?” Whenever I have some spare time left, I usually take my camera with me. It’s not particularly new, not even a digital one. My parents already used it during vacation before I was born. It’s a Praktika Nova 1 - capable of taking breathtakingly beautiful images:

There’s just one catch: The camera is not self focussing, nor does it come with an internal exposure meter. Instead the one I have is to be used separately before taking the picture.

However even after reading just a tiny little bit about f-numbers, exposure times initial pictures I took four years ago were astonishingly beautiful. Since I regularly tend to go out just for taking pictures.

Freetime camera, free time