Robs Laws

I was talking in a Software Engineering lecture today about "Rob's Laws" amongst other things. I think it is time these were finally written down.

1. Any given computer is too slow. No matter how fast you think it is when you get it, after a while you will think it is too slow.
2. Any given project will take longer than you think. Even (or especially) if you allow for this. The only exception to this rule is a project you won't get paid for, or one where you have massively misunderstood the requirement and are therfore doomed.
3. A program that is useful will have bugs in it. The only programs that can be proved to be correct are too small to do anything that you might want.
4. A highly successful, fully working, system which contains hardware components will just about always have a massive "kludge" somewhere in the middle of it. This is the bit that has to be there, otherwise it won't work. Nobody will completely understand why it has to be there, or what it does, but they do know that if you take it out the system stops working.
5. A customer will never ring you up and tell you their program is working fine. Never. If the phone rings, it is always bad news. Silence either means they haven't got round to testing it yet, or it is working fine. At the point where you think it has gone quiet for long enough for it to be definitely working the phone will ring and they will tell you they've just got around to testing it and have found something they don't like.
6. As soon as you assume something about what the customer wants you are doomed. For sure.

Update on Saturday, December 2, 2006 at 08:48AM by Rob

Hmmm. I've been thinking further about this. I reckon that law 4 is probably a bit harsh. I think it applies to projects involving hardware (they do seem to need this level of magic) but not always to straight software ones.