One of our developers posted an article on our corporate blog about backward compatibility. He discusses 6 conceptually different ways of handling the backward compatibility problem in an application or API.

Backward compatibility is something that is often not taken into account from the start when developing a project, and it can bite you at a later stage. So I think it's a good read.

You can find the post here.

Recently, Google opened a search engine that will appeal to all developers: Google Code Search, for searching through all available source code on the web.

While this is great to find example usages of functions, or to find security vulnerabilities, a far more fun thing to do is delve into the frustrations developers encounter while developing code. Frustrations that are filtered out by the compiler, and are hidden away into source code comments.

This search for example is a nice one, and I had a good laugh at the first result of this search.

You can also see how programmers think about certain big corporations when using their API's.

It's also fun to see how much faith developers have in their code.

Finally, it's nice to have a way to see how much legends such as 'foo' are actually used, and that some developers even put prayers in their programs.

One tip: if you search for PHP variables, prepend the $ with a \, as Google Code Search supports regular expressions, so you have to escape certain characters.

I just read Clay's rather opinionated post about Loner applications.

I posted my reply in his blog, but since the submitbutton didn't seem to work and my reply was rather lengthy anyway (which might very well be the reason it didn't work), I decided to post it here instead.

When I read Clay's post, at first I thought 'hear hear!' and completely agreed.

But then I changed my mind.

The fact that Da Vinci painted the Mona Lisa never stopped others from painting similar paintings. Neither should Coldplay and Keane not exist because U2 already makes the best music in the world anyway.

There are many reasons why people program. The most common reason of all is 'fun'. I've heard tens of times 'I know there already exist standard apps for this, but I just wanted to learn how it works, and it was fun'.

And this is every free programmers right.

None of these programmers force you to install their apps. They just show the world what they have created. And people either like it and install it, or they don't.

One example: had Larry Page and Sergey Brin thought 'why built a search engine, we already have altavista, lycos and metacrawler', they would never have turned the search engine market upside down.

Just not developing anything new because 'it already exists' is simply killing innovation. Every now and then a new app WILL succeed in being better. 9 out of 10 won't, but it's that 1 in 10 that makes all the other efforts worth our while.

So please, develop all you want. Be creative. But use common sense. Reuse what you can reuse. Think about extending existing apps instead of beginning from scratch. And I do agree with Clay that interoperability is important if you want others to use your software. But we do n't pay you to develop this, so it's really nothing more than an advice. And if you code just for fun, do whatever you like. It's your own spare time. Who are we to judge what you should and should not create?

A few weeks ago, we had a major problem with software we'd written for a client. It was software for sending mailings to the client's customers. Suddenly there were many reports of clients receiving multiple mailings instead of just one.

The problem appeared to be in our test code. The software had a 'test' mode for testing the mailing by sending it only to the author and a small test team. It appeared that for some reason, all test mails were being mailed to the customers as well.

This problem would not have appeared if we had applied what I would like to call 'defensive programming'. Take a look at this example, which is an oversimplified version of how the software worked:

 
  ....
  if ($mode=="test"}
  {
     $recipients = "testers@somedomain.ext";
  }
  else
  {
     $recipients = "customers@somedomain.ext";
  }
 

What happened was that due to some change in the software, this particular piece of code, along with a bunch of other code, was refactored into some other function, where the $mode variable ran out of scope. Result, $mode=="test" is never true, and we send all the test mailings to all our customers.

The defensive programming approach would be like this:

 
  ....
  if ($mode=="production"}
  {
     $recipients = "customers@somedomain.ext";
  }
  else
  {
     $recipients = "testers@somedomain.ext";
  }
 

Would the same problem appear, the bug would have been less awkward, as only the testers would receive the mailing. Ofcourse this doesn't solve the actual bug, but it helps fight bad results.

In essence, you have to expect the worse. Write your code with Murphy in mind. Anything that can go wrong, will go wrong at some point. Especially when relying on (global) variables that are defined at some distance from the code where they are used, so it's easy to not notice the problem until it's too late.

P.S. We've released ATK 5.4 this week and, [shameless plug], my little .com adventure epointment.com has gone live this week in a very basic first version [/shameless plug]. For those interested: the epointment site is entirely written in ATK, while the backend server was written using Ruby on Rails, linked together via SOAP. What better way to compare ATK with Ruby on Rails