Geek Rants

1) Design first, then code
Okay, things are going political now, but even though you will find many many people who disagree, I still feel that this is the single most valuable lesson that I have learned. Designing first and then coding simply doesn't work. The problem is that this is so counter intuitive that you more or less have to find it out for yourself.
I think every programmer has experienced a project with no planning turning into a mess. Changing such code can only be done with hacks and patches to everyones great frustration. It is at that time that you realize that the only decent way to code is by designing things right from the start. Only now the frustration is even greater when you realize that your beautiful design isn't prepared for exactly this new feature that you are to implement now. What to do then?
You should think before you code. Go ahead, but think for hours, not days. Don't kid yourself into believing you can sketch an entire design document with UML diagrams and everything without making mistakes. At least, don't think you can do so any faster than you could have simply written the code.
Now, if you're not familiar with agile methodologies such as eXtreme Programming, the whole concept of evolving design sounds like the very problem programmers are trying to solve with all their clever ways of abstracting things out. And indeed, evolving design only works well if you follow a number of practices. Short iterations, automated testing and frequent refactoring being the most important.
I suggest you read Martin Fowler's excellent article Is Design Dead? which explains it all a lot better that I am capable of.

2) Be tolerant with input and strict with output
A function that accepts a vast variety of input formats is harder to test and harder to validate.

3) Use the singleton pattern for variables that you KNOW you should have only one instance of
Global variables are evil. And just because you put a such into a class which in turn is put into a design pattern from nothing less than the GoF book, it is no less so. On a more philosophical level, what is "global"? "Global" in programming terms means per process. Which is sometimes fine but it is actually a rather arbitrary resolution given the distribution of many software systems. A software system can consist of many processes running on many machines - and each process may internally run many threads. In this perspective, process-level variables are really somewhat of an odd size.


4) Write lots of comments
I think my colleague Lars Thorup pointed out a very good test for comments: they should contain the word "beacuse". This way, you know that you are answering a why rather than a what.

The user has never seen it before, they know nothing about it! That is their valuable commodity: innocence. You need to learn how what they think without being tainted by knowledge of it.
Keep your mouth closed and your eyes open.

A mass of specifications without being implemented does NOT help. If one can not trust whether a detail in a spec has been implement, never mind works correctly then the spec is fairly useless. They are better than nothing but only just.

There is no return on investment for ideology.
Slowing down development for the sake of ideology doesn't help you become more profitable. The question should be is this a step in the right direction, not is this a perfect solution.

Keeping a note of why a major option was not chosen. Recently I have seen a case where it was company policy to document why a choice was decided against. The purpose was to keep a corporate memory and to not revisit the issue at a latter date whithout understand the reasoning that went into the original decision. Of course there are many possible options so this can only apply the the major options, not to every possibility under the sun.

Bug tracking software - we dont need no stinking badges. We're real men, we keep it all in our heads.
Bug tracking is such a fundamental part of developing software that it is amazing that some software house still haven't yet got themselves a bug tracking system.
How they can imagine that they are professional without it is beyond me.

Sale cycles ALWAYS take longer than expected.
Start small when delivering a new platform. You need to prove yourself, and a smaller customer is easier to sell to.

If you want google to remember what you have previously searched, log in to http://www.google.com/searchhistory
I can't decide if I should be worried about this or enjoy knowing that I can get back to an old search.

When you don't get programmer buy in, you will still get the feature delivered. What you want get is the programmer thinking about the "real" problem they are trying to solve. The programmer will be focused on delivering what they were asked to do. They could be thinking about what would make it a better product, but if their heart is not in it "why bother".

It seems that items that are no longer hits still can sell well. The Long Tail from Wired
Clearly books(Amazon), music(iTunes) and video(Netflix) are taken. There must be mores things like that, that have long tails.