www.hans-eric.com

It’s a well known fact that we regularly introduce errors with the code we write. Chances are slim to get it right on the first try. If we do, the risk is great that changing requirements and murdering deadlines will mess things up later on.

It’s also well known that the cost of failure increases with time. The sooner you discover the flaw, the easier it is to fix. In other words, if we are going to fail, there are good reasons to do it fast.

When developers talk about failing fast they usually refer to the defensive coding technique that is based on assertions and exception handling. It’s true that assertions are the very foundation of failing fast, they should be your first line of defense against bugs. But it doesn’t stop there. Failing fast should pervade your whole process of making software. You should fail fast on all levels.

The most effective fail fast-technique is automated testing, the fastest way to get feedback. Be sure to write the tests first. And don’t just automate unit-testing; integration and acceptance testing are often easier to automate than you might think. The key is to isolate your code using mock objects.

The fail-fast property doesn’t apply to code and systems alone. It should be used on the project level too. By using agile practices like short iterations, small releases, and on-site customers you create an environment of continuous feedback. It will help you steer the project to success, or – by failing fast – avoid a disaster. Kate Gregory puts it this way in a nice post from 2005:

“Failure can be a good thing. If it saves you from following a doomed path for a year, you’re glad to have failed early rather than late.”

Failing takes courage, failing increases your knowledge, failing calls upon action. That’s why I like the habit of Failing Fast.

This was the fifth post in this series. Here are the other Tools of The Effective Developer posts:

1. Tools of The Effective Developer: Personal Logs
2. Tools of The Effective Developer: Personal Planning
3. Tools of The Effective Developer: Programming By Intention
4. Tools of The Effective Developer: Customer View

SEO is obviously something that is occupying a lot of people’s minds nowadays. Digg and other community websites are full of posts with the three-letter abbreviation. The challenge is to outsmart the search engine algorithm so that your content (well, ads) will show amongst the first search results. The number of SEO experts out there are legio, but so are the skeptics. Alastair Revell, for instance, thinks that all you need is a good grip of basic web design.

“What I believe is that writing search engine optimised pages is part and parcel of good web design and not a black art to be practised by specialists.”

I agree with Alastair on this. To me, SEO with the sole purpose of climbing as high as possible on the Google ladder, is a lot like cheating. It’s like skipping a cue. The effect is that more legitimate content could be pushed downwards. The problem then, is that if some does it, everyone needs to follow or lose their legitimate rank.

A parallel can be drawn to driving in big cities: in order to prevent cars from behind to pass and take your place, you need to keep a short distance to the car in front. This way of driving use up more fuel than necessary. It requires you to accelerate faster, and break more often than what is optimal. The same is true for SEO. The time you spend on optimizing search engine results is waste in the sense of content quality.

Instead of worrying about duplication or other SEO related problems, your time is better spent on improving content and users’ experience. In my opinion, that is the only way to be a long-term winner in the Search Engine Game.

I sometimes come across a blog post that makes me want to reward the author a little more than the normal Digg, Reddit or Stumble voting. This is usually the case for content that enlightens or inspires me, or just makes me feel good.

I wouldn’t go so far as to pay the blogger, but since I’m willing to spend a little time there is another way. Here’s how I do it:

When I decide to reward the author, I scan the post for an ad that catches my attention. If (and only if) I find an ad that is worth spending at least 30 seconds on, I go ahead and click it. In that way the author gets a little money (usually a fraction of a dollar), I accomplish my goal of rewarding him or her, and the advertiser gets the chance to present his offer to someone who is suffering from severe ad blindness.

Please note that this is not some kind of click fraud. I only click on ads that interest me, and I do spend time to investigate the offer. In fact, my habit of rewarding good posts is every advertisers dream. Since I use Firefox with the Adblock Plus extension, I need to turn that off in order to see the advertising on the page. Nothing but the wish to reward the blogger could make me go through that procedure.

I stumbled upon this really interesting site. It implements a new kind of site navigation that is really cool. It’s actually a research project that tried to create a user interface which requires no clicking.

For me it was a mind-tumbling experience, but I quickly got a hang of it. I even liked it to some extent. I had two major problems with it though: First there were a lot of movement going on. A little too much for my old fashioned taste.

The second and more important problem was that the mouse pointer got in my way while reading. In a normal click-based interface I could just drag it out of sight, but here I needed to have it hovering over the item to keep it enlarged. This was annoying, but they should be able to reduce the problem with more whitespace around the enlarged items.

I haven’t tried the interface enough to come with a deep analysis, but my guess is that it won’t replace the traditional click-based navigation. At least not in the near future.

A post on Jeff Atwood’s excellent blog inspired me to write up the fourth element of my Tools of The Effective Developer series. This time I’ll handle the habit of taking the customer’s view.

Jeff states that the primary responsibility of a software developer is not to write code, it’s to solve the customer’s problem. (Otherwise, using my definitions, he is a programmer and not a developer.) This calls for the habit of taking the customer’s view in every step of the development cycle. Make it a habit to ask yourself the question: In what way does this matter to the customer? This simple question is like a good friend of mine. It’s stopping me from making costly mistakes and helps me focus on what’s important. Like getting the right things done, and not just things done right.

By taking the Customer View you help preventing technology-based decisions. I once read a report that was going to be the basic input for a decision to replace a legacy system. The author’s main reason was to have an object oriented system. Why would this matter to the customer? While there are perfectly good reasons to have an object oriented system, none of them could be found in the report. Nor could any of the really valid reasons, like usability and functionality issues.

The report-writers obviously didn’t take the customer’s point of view, but the decision was made none the less. So what happened you ask? Still not finished, many times the initial budget spent.

Being able to look upon your work from the customer’s point of view takes empathy, the finest characteristics of them all. Exercising it regularly is something all of us should do. That’s why I like the habit of taking the Customer View.

Here are the other posts in my Tools of The Effective Developer series:

1. Tools of The Effective Developer: Personal Logs
2. Tools of The Effective Developer: Personal Planning
3. Tools of The Effective Developer: Programming by Intention

This is the third post in my Tools of The Effective Developer series. The other two discussed the habit of keeping personal logs, and the habit of daily planning. Now the time has come to the habit of programming by intention.

Please note that I’m not speaking of intentional programming, which by the way introduces some interesting concepts. Instead I refer to the simple kind that only requires your brain and the programming language of your choice.

So what is programming by intention? Well, I like to describe it this way: if you are to implement a new set of functionality, and you don’t start with the implementation, nor the programming interface, but you start writing the code that is going to use it – then you are programming by intention.

Why is this way better? The short answer is: Because we are lazy. The long answer is: We humans usually seek the simplest solution. Start with the utilizing code and you should find yourself pushing complex code and decisions right where it should be: behind the programming interface, nicely encapsulated. We also focus more on the task at hand, which decreases the risk of committing the sin of premature generalization.

Programming by Intention is probably the easiest effective developer habit to acquire. It can be done at all levels of abstraction and there is no overhead cost. Therefor it’s my favorite habit.

One of my favorite quotes comes from Ron Jeffries on his blog Hot Needle of Inquiry:

“the river is moving, and if we don’t keep rowing, we are going to drift back downstream”

The quote reminds me of the importance of self-improvement. If we stop learning we are nothing but dead material in the stream of life. Ron seems to have stopped updating his blog, which is sad because it was one of my favorites.

Today I read a really interesting post on Debasish Ghosh’s blog. He shows how you can get object-orientation in a functional language using closures. I knew it could be done, but I hadn’t seen it in code before. Neat, but I received the real learning opportunity from one of the comments, in which Gabriel C. states “LOVED the Koan”.

I didn’t have a clue of what a Koan was, but Wikipedia came to my rescue:

“A koan is a story, dialog, question, or statement in the history and lore of Chan (Zen) Buddhism, generally containing aspects that are inaccessible to rational understanding, yet that may be accessible to Intuition.”

Thank you Debasish and Gabriel, you made me exercise rowing today too.

I just finished reading The Google Story, by David A. Vise. I can’t say it’s a great book. Some parts are terribly boring, stuffed with uninteresting facts and examples. But there were chapters that made me long for my next visit to the toilet. Here is the list of things that caught my attention:

1. Larry and Sergey built their product first and raised money later. It’s so much easier to sell your idea if you can back it up with a real and functioning implementation.
2. The two founders didn’t start with their eyes on the money. In fact, they had no idea how to monetize their search engine in the beginning. Instead they were focusing on providing the best search experience they could. The focus on usefulness is what laid the foundation to their success. People noticed, trust was built.
3. A Google employee (a Googler) are free to spend one fifth of his time at work on a private project of his own pick. One day each week, free to spend on anything that interest you. You’re not just free to do it; you are supposed to do it. It’s your job.
   To me that sounds just like employee heaven, but the employee is not the only winner. Some of these private projects grow and end up in valuable products for the company. Just look at the wide range of services that Google provides, many of them started out as private projects.
4. Google takes care of it’s employees. Free healthy food and day care for my children would make my life so much easier. That’s another win – win deal between you and your company.

If I ever get to build my own start-up, I will use Google as my template.

Cheers!

I have a confession to make: I used to be addicted to debugging. Yes, it’s true. When I got hooked – damn you Delphi – I wasn’t able to see the dark side, the demonic side of the debugger. It lured me into the path of quick fixes. Heed my warning: debuggers are bad!

Fortunately I’m one of the lucky few who have been able to recover from this particularly addictive behavior. I’ve been clean – thank you jUnit – for almost 5 years now. And you can do it too, you can let go of the safety zone that these integrated debuggers provide, and break free just like I did.

The first thing to do is to realize that there is a better alternative: test-driven development. To get rid of a bug, the right thing to do is not to fire up your debugger, but to write a unit-test to reveal it. If necessary, keep writing tests and go deeper and deeper into your code. Eventually the tests will tell you what is wrong, and they’ll even point out a solution for you.

I know that using a debugger may seem like a faster way to find and extinguish a bug, but that is just an illusion. Here are the reasons:

1. TDD improves the design. Being forced to think testability tends to divide your code into small manageable pieces. This will make your code a bad breeding ground for bugs.
2. Tests remain useful for a long time. They become an addition to your testing harness, which helps protecting your code against future infestations. The work spent in a debugging session can never be reused.
3. Unit-testing saves time, a lot! While this isn’t immediately obvious, the long term effects are huge. Think of it: all those debugging sessions can be run automatically at your command, whenever you want, how often you want, and in just a matter of seconds. All you have to do to achieve this is to let go of the debugger, and write relevant tests.
4. Unit-testing gives you courage. There’s nothing like a good harness to make you feel invincible. I still remember the first time I felt the real power of unit-testing. I was working on a huge legacy application and had developed a new set of functionalities, using TDD for the very first time. Several months later I realized I had to do a major rewrite. The rewrite was risky business and took me a couple of days to complete. When finished, I ran the unit-tests which all came out green! I could be confident the program worked just as before the rewrite. And the best part: I drew the conclusion out of just five seconds of testing. Boy, I still get the goose bumps.

[PREACHING OFF]

Of course debuggers are useful tools. In certain situations they are even invaluable. For someone who’s new to the software they provide a great way of getting to know it. The problem is that a debugger makes you lazy. So be sure to get rid of it as soon as you identify a testing strategy.

Cheers!

According to this slide show, the team behind D is thinking of incorporating an interesting addition to the language: The interchangability of a.foo(b) and foo(a, b).

This makes some interesting uses available. For instance, one could do something that looks a bit like monkey patching, adding functionality to library classes.

real round_to(real n, uint d) {
  real b = 10;
  real k = pow(b, d);
  return round(n*k)/k;
}

With the proposed change I could use the round_to function like this:

real a = 9.4334566;
real b = a.round_to(2); // => 9.43

I would also be able to do this:

int next(int a) {
  return a + 1;
}

int b = 3.next; // => 4

And while we’re at it:

void times(int n, void delegate() dg) {
  while(n\-\- > 0) {
    dg();
  }
}

5.times({
  writefln("Look at me. I'm Ruby!");
});

Of course this isn’t really monkey patching. The functions doesn’t actually become a part of the class, and thus cannot use polymorphism or access private members. In all respect this is just syntactic sugar, but I like it. It gives you the illusion of having a dynamic language.

I haven’t seen this particular feature in any other language before. Does it exist elsewhere? Does it have a name? If not, I think Donkey Patching would be a suitable one.

Cheers! 🙂