Michiel . van Vlaardingen

For Observu implementation we are using Pivotal Tracker to keep track of features and progress. I’ve posted a full review on our Observu Blog. To summarize:  the idea of having a single ordered list of features instead of just a bunch with priorities is amazing. It gives you so much more information and forces you to make decisions on what really needs to happen and what needs to happen first.

You’ve got so many ideas in your head that you just don’t know where to get started. As a result, you start procrastinating on stuff you do feel passionate about. At the same time, you’ve got enough energy and are motivated to get stuff done.  It’s a bit contradictory state of mind, that happens to me once in a while.

The problem is anxiety to commit to one project and  even more so: leave all those other things alone.  I believe the key to overcome this problem is to start on anything.  In the end it does matter much more that you’ve made progress and added value than it matters which choice you make.

Of course, that’s easier said than done. ‘Pick anything’  is still a choice and choices are hard. Therefore I use a very simple solution:  pick the easiest task that still adds value.   In the end you probably will have to do all those tasks anyway, so why not start with the easiest one?    Especially  in programming,  getting anything done, will give you more context to solve the next task.  Tasks that may have seemed daunting at first, become easier and better defined when the system around it takes shape.

In programming you often have the choice between  quick and dirty (often copy/paste)  and  smarter and DRY (don’t repeat yourself).  The assumption is that the latter will save you time in maintainance at the cost of some more initial effort.   However, I am convinced that independent of what you choose it will haunt you at some point in time.

It’s not difficult to imagine how copy and paste will haunt you:   things will change… and if it’s one of those things you’ve copy and pasted a million times over the place,  you’re not going to be happy.  Especially if the initial code is not yours, you will have no idea where it has spread and if changing it in one place will fix it everywhere.  (Not to mention the slightly altered cases in some place, which will render a simple search useless)

However, the smarter way can also haunt you. First of all,  ‘smarter’  is also  often harder to understand at first glance.  You need to find out where stuff is defined, as code is less straight forward.  Also, DRY often means generating some output based on a more abstract specification. (either a configuration structure or maybe even a DSL (Domain Specific Language)   That’s all great, until there is a feature that doesn’t fit your framework. (and you WILL encounter this at some point)  You either have to spend a  lot of time to incorporate it cleanly or fix it in an even less elegant way than the one you were trying to avoid.

I’m not going to say you need to stay away from smarter programming, however you must realize that it will not protect you from having to do more work than anticipated for what are essentially minor changes.   Every line of code that you put in, will make it harder for some unknown features to be added later on as you can’t foresee everything.

A few days ago I wrote about procrastination and by coincidence I came across an article about changing your working method to embrace the interruptions, instead of trying to find long stretches of concentration (‘the zone’). It is a nice read, however, more importantly in the comment section I came across something that really appealed to me: The Pomodoro Technique.   I had seen it before, but it didn’t jump out to me at that time.

The basic idea is:  work for 25 minutes on a single task, with a timer ticking back the time left  and then take a break. This is augmented by a few other important steps, such as: noting down your distractions, evaluate them only after the 25 minutes are up and crossing of the completed intervals per task.

As I don’t have a proper timer yet, I looked for a software one, that works under Ubuntu as well  and came across:  Focus Booster.   It makes the ticking sound and also very nicely automatically starts your 5 minute break timer after time is up.

I just started using it, so I’ve only done a few of these ‘Pomodoro’ intervals, but I feel very confident that this will actually work as it makes you very aware of the distractions you need to avoid/delay  and the time you have available.  Starting the timer gives a feel of commitment about doing something NOW instead of  in a few minutes. Furthermore, having a timer tick back, give you back a bit of that deadline stress that makes you feel productive, without the disadvantages of real deadlines. And, not unimportant: it feels good to cross of real productive time.

My whole life I’ve been trained in sticking to deadlines.  School and University is nothing but doing a reasonable amount of work  for an event fixed in time (tests,  reports to hand in, etc)  Which, if you are anything like me,  means  procrastinating until the exact moment it can’t wait any longer an then work very hard.    Procrastination is rewarded:   it gives you more free time  and good results, so by the time  you get to your graduation, it has been perfected to find exactly the minimum amount of time needed to still get good results.

However, this skill gets you nowhere on real projects.  Projects like  your graduation or  developing a new product, where there is no fixed ending and you really want to get done as much as possible, as soon as possible.  ( I can probably make a todo list that fills the rest of my lifetime )  Of course there is the fun/interesting stuff that will never get you stuck, however every project (even the most fun ones)  have those tasks that you just need to get done. Not being able to do so in a timely manner is very frustrating.

The first obvious way to try and fix  this, is to create artificial deadlines, to get back that feel of urgency. However, deadlines that you set yourself don’t work, I’m just way to much aware how arbitrary they are.

Furthermore, on real projects, the amount of work is not known in advance. So there is no way to determine when to start to finish ‘just in time’. On the other hand lots of stuff you delay, might take far less time than you expected.  (You actually spend more time thinking about how much time it is going to take)

Procrastination is also closely related to getting ‘into the zone’ (Read: Joel Spolsky on that topic), but to be fair,  there are also lots and lots of activity that do not require any ‘zone’ at all. So, I feel a strong urge to  ‘solve’ this productivity mystery.   One of the obvious choices is reading about the ‘getting things done’  method. However I’ve never succeeded in making it work for me:  Writing everything down in a system, makes it even more overwhelming then just managing it in my head, as my brains are a lot better capable in hiding the ‘someday/unimportant’ stuff that I come up with.

I’m still in doubt though whether this is not just your brain telling you that there is only a fixed amount of productive time and the idle time in between is just needed to solve complex problems. However, there are a few things I did find, that do help:

• Committing to a task, by telling someone that you will do it: ‘right now’.  (Not some time in the near feature, really: NOW)
• Do another task instead, that you feel really passionate and confident about, to get going
• Split up your tasks into such small subtasks that it’s impossible to not finish it (So every time you do any work, you actually finish something, instead of going from   ‘busy’ to ‘still busy’)
• Work together on a project,  you can keep each other going  ( I believe that is one of the biggest arguments in favor of pair programming)

Are you a procrastinator as well?  And what do you do about it?

My previous post was a bit generic, but now I’ve encountered the perfect example of how building a Framework slows you down:

Lets say we are building basic user account confirmation. In a plain-php way I would write:
mail($email, “Your account confirmation”, “….”);

Now in our framework it has evolved to something like:
mail($email,  $settings->getSetting(CONFIRMATION_MAIL_TITLE), “…”);
and the actual text is loaded from the settings table in the database (so our non-tech partners can edit as well).  So all is now configurable and nice and quick and smart right?

NO, because in a new project, the database is clean, so I get a nice “confirmation.mail.title setting is not defined”.    And now this is where I slow myself down:  Instead of just adding this entry to the database I think:  hey, I shouldn’t get this error, this should have a default setting.   So now instead of having to write this one simple line of code I have to:
- find a way to store all default settings in some file in the framework distribution
- adjust the settings mechanism to use those defaults if there is nothing in the DB
- retrieve all data in the settings table from a previous project and store it in the file

And as soon as I have this thought cross my mind, the focus on the original project is gone and we are back at the infinite task of the perfect framework.

If you develop a lot of projects and are a bit like us, you will recognize this: the reusability dream.  It starts of with a little itch that you are not taking advantage of the knowledge and work in the previous project.  You start with some simple database handling and utility functions and all is fine. For a while…

The next stage is actually creating reusable functionality….   The reason is that you know it will haunt you do the same thing in multiple projects  using copy/paste  as it will need to be fixed some time.

This is also the point where your library turns into a framework: Everything needs to be done in a particular way to fit in your nice reusable scheme of things.  Your project no longer just uses a few nice functions,  it completely depends on it.

As I’ve written before the reason I like plain PHP is what I call the notion of proportional time.  The time you spend is proportional to the complexity of the feature you are building.

The problem with frameworks is that they have smart things built in. The framework makes it easy to do stuff that usually takes much more time. However, it’s almost never smart enough. At this time your framework has evolved so much that every time you will have to pick your poison: either go through a painful adaptation to your framework OR recreate it without your framework and go through the painful tinkering an bugfixing that’s all built into the framework… how frustrating.

In our case this stage expresses itself in SLOW development.  Every small step forward becomes way more complex than the actual feature that you need to built.  It’s completely against the principle of proportional time.  You are locked in your own Framework.

Now is the time that you need to consider whether or not: worse before better applies or that it’s just going downhill.    Two years ago we had a framework where the latter was clearly the case and we just had to drop it.   The problem with it was that it was really an all-or-nothing approach.  In our new framework we can easily take just a step back and use only part of the framework until we have clear ideas about the next level.   We still experience the  locked-in situation from time to time, but it’s much easier to get past it.

Our path to Framework enlightenment has the following steps:

• No collisions: make sure that the library/framework does not collide with other code, this will mean that you can drop it into an existing project without the need to rewrite it first
• Layers: create layers of tools, functions and abstractions. If one layer is to restrictive, you can at least use all tools from the other layers below it
• the framework needs to be out of the way:  You must always be able to do things outside the framework and still access it’s data.
• Everything needs configuration and even more important: defaults
• Override everything: be able to replace small parts of functionality without the need to recreate it completely.
• Constants do not exist:   at some point you will want to be able to manipulate it with code
• Move everything to the framework: if you want to reuse it, don’t create it inside your project directory
• Have a (documented) process (including best practices) to create new things for and using the framework.

We are not there yet, but are confident that this time that the benefits outweigh the extra effort.

We recently decided to choose Python over PHP for a new project. I did not know Python, so I’m currently learning it.  I was always in love with the C like syntax of Java, PHP, etc. and could not really imagine someone liking anything else. However, I have turned around now.  I really, really like Python’s whitespace sensitive approach. It makes all your code look so clean and compact.

It is clear from the start that Python really forces you to take one approach. That seems inflexible at first, but ultimately it gives you less to make a decision about and improves consistency of the code.

I do think there is a lack of documentation at some point. The core language and most important modules have excelent documentation, but that is not true for everything, so sometimes I really felt the need to look at the source.  Which fortunately is very very easy to read.

What really helps me to learn Python as fast as I can is the commandline interpreter, which allows me to simply check what works and how data looks. Furthermore, the PyDev environment is a really great help, with immediate feedback about syntax errors.

If you did not give Python a try yet, please do, even if it looks a bit weird at first, it is really nice to work with.

The use of JavaScript has evolved over the years.  In the early days we would address a form element using:  myform.elementname .      Nowadays we prefer to use myform.elements['elementname'].   A related problem I ran into and only solved yesterday was, why    myform.submit();  was not working. Google presents the answer as the first result: www.thescripts.com/forum/thread542837.html for the query form.submit does not work.

Because my button was named “submit”    myform.submit refers to the button instead of the function.

Today I encountered a similar but harder problem.    Imagine this form:

<form id=”f1″ action=”go.php” onsubmit=”return ajaxSubmit(this);”><input type=”hidden” name=”action” value=”something” /> ….</form>

So I use  document.getElementById(“f1″).getAttribute(“action”);   to get the action and submit using AJAX.   Which works perfectly well in Firefox… and not in IE…

Apparently  IE does not really get you the action attribute but simply  object.action…. which in turn is the input element instead of the action attribute, similar to the first problem.  Unfortunately I can’t come up with a way to fix the script, so I had to replace the HTML all over the place.  (removing the action named input element by defining the action as action=”do.php?action=something”).