Archive

Archive for February, 2011

Inauspicious Beginnings

February 15th, 2011 3 comments

Whenever I feel a bit intimidated by the sheer scope of the work I’ve set out for myself, I pause and take a look at the inauspicious beginnings of the great IT giants of today.

Some of them are available here at The Telegraph

I especially love the page of Google, with the big exclamation mark. The exclamation mark (!) tells me that they wanted to be a Yahoo! me-too clone. Lucky for us all, their vision become much larger at some point. Otherwise we’d still be navigating subject directories!

You can find many more examples of these in the waybackmachine (for all you Rocky and Bullwinkle fans!).

My my, fortunes have changed significantly, haven’t they?

One of these, Twitter, is only 4 years old. Facebook is less than a decade old.

What will we see in 10 years from now?

Easy Procrastination Avoidance Advice

February 8th, 2011 3 comments

My mother gave me the cure for procrastination when I was 6, and I could not start my homework. She encouraged me to ‘just start it’ (her exact words were, ‘just sit down’, I believe).

Today, I came across proof from the field of psychology that she was right!

Let’s go back a few years to the late 60s.

A prominent Russian psychologist, Bluma Zeigarnik , noticed an odd thing while sitting in a restaurant in Vienna. The waiters seemed only to remember orders which were in the process of being served. When completed, the orders evaporated from their memory.

Those who dable in cognitive sciences (like me for example!) refer to this phenomenon as ‘closure’. Closure effectively flushes your short-term memory. This is why early ATMs used to cause people to ‘forget their cash cards’; once people got their money, they walked away (without their card) as their ‘task’ (i.e. get the cash) is now complete. It wasn’t the people’s fault (they beat themselves up for forgetting their card!), but the designer’s fault for not being aware of this closure phenomenon. This is why nowadays, the ATM gives you the card, and refuses to give you the cash until you have taken the offered card.

So… the answer to procrastination is.. (wait for it !) …being in a state without closure. The easiest way to get there is to start something, as by definition, until it is complete you are not in a state of closure!

Zeigarnik proved this in the lab. She asked participants to do twenty or so simple little tasks in the lab, like solving puzzles and stringing beads (Zeigarnik, 1927).All standard stuff.. EXCEPT that  some of the time they were interrupted half way through the task.

Afterwards she asked them which activities they remembered doing. People were about twice as likely to remember the tasks during which they’d been interrupted than those they completed.

When people manage to start something they’re more inclined to finish it. Procrastination bites worst when we’re faced with a large task that we’re trying to avoid starting. It might be because we don’t know how to start or even where to start. Figure out one piece that is mandatory for the final solution, and start chipping away, and before you know it, it’s all done.

Zeigarnik’s gift to us is the lesson that one weapon for beating procrastination is starting somewhere…anywhere. Carpe Diem. Get back to work now! :-)

Technical Debt — Defined

February 7th, 2011 No comments

Designing software that is meant to be used requires that you put the user experience front-and-center when coming up with the design.

However, when  you have functionality that you need to add to your system you have two ways to do it,

  1. Quick and messy – you are sure that it will make further changes harder in the future. This involves actions like hardcoding parameters or bringing in libraries that you don’t completely understand.
  2. The other results in a cleaner design, but will take longer to put in place.

Ward Cunningham coined a wonderful metaphor (Technical Debt) to help us think about this problem.

In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

I’ve made some choices during my career where hard deadlines, or the limited maintenance nature of the project meant that the effort for very clean code and architecture was not justified. However, one practice that I would advocate is to keep a copy of Bugzilla around where you can log all the ‘todos’ required to refactor, clean-up and enhance robustness in your project.

When you have debt, you have to keep track of it so that you can pay it off. Any other alternative is reckless and irresponsible. The metaphor hold equally well in the domain of software engineering as it does in the field of personal (or corporate) finance.