October 23, 2005

Consultants need to behave like SM hookers

If you are a consultant your customer is King. And you need to treat him like it.
If a customer comes to a sado-masochistik hooker and asks the girl: "Please spank me". The girl will answer him: "Dude that's gona hurt". If he says: "Yes I know - but thats what I want" - she will start spanking. If your customer asks for something you think is not a good idea you need to explain him all the consequences of his not so good idea. If he comes back to you and says: "Knowing of all the bad consequences I decided to want it anyway" - you need to implement his wish.

October 22, 2005

little kids count from 1

Little kids count from 1 when they play hide and seak but as a software developer you better count from zero.

If you can’t organize a bookshelf stay out of DB development

There is a lot of analogy between organizing a bookshelf and a database table. First you need to decide your primary key. Do you organize your books by author or by alphabet of the title or year of publishing? Obviously you wish that this should be the most obvious sorting of your books. It totally sucks being in a Blockbuster and you search for the new Robert Redford film and the stuff is organized by “drama”, “comedy” etc. and you don’t relay know what it is.

Second most annoying bummer: You rent out the next CD from “Six Feed Under” and you get the same freaking CD you had last week because they don’t have the series number on the cover. You want your primary index to be unique.

Ok – you are ready to put your items into the shelf. Well - I kind of would make sense if you put it into the shelf in the way you want the stuff to be ordered. The physical order should match the logical order that you want to have. That’s your clustered index – it makes sense to take the same as your PK. Now you can write on each shelf hints hat help you searching faster. Upper board is A-D, next one is E-G and so on – you got your cluster.

But now you what to search all books that deal with e.g. Newton. That’s where they have those little card index boxes with other indexes that make it easy to find stuff that is not your primary order. They are fast too, but it takes a long time building them. Just picture what you have to do. If you buy a new book, then you put it to the right spot in the shelf and then you have to write an index card for each index you have. Be economical defining additional indexes.

Here is what my grand dad did his whole day long. He was retired and had a huge library, but all his bookshelf where stuffed with books. Every time he bought a new book – lets say in H-K he had to move one book from the H-K shelf to the L-N shelf and so on. Finally he took out a book from each shelf and moved it one down up to Z of his library. He was retired so time did not matter but it matters for a DB developer. That’s where the fill factor becomes handy. If you leave a little space on each shelf – integrating new books will be much faster. The more you plan to add the bigger the spot should be that you leave on each shelf – same with the fill factor in a database make it big if you plan to insert a lot.

You don’t want to find out in a Victoria Secret store that you are zipping

Realizing in a Victoria Secret store that the zipper of your pants is wide, wide open - that’s probably one of the most embarrassing moments you can experience. But that’s how you should feel if someone finds out that your code throws an “Object not set to an instance of an object”. They should have changed this message into “This peace of software shit was most likely coded by the dumbest member of the team”. If you find out that you did it, try to close your zipper as low-key as possible.

Mole – dig back to the surface and check where the others dig

Software developers all other the earth tend to behave like moles. They start digging into their work. They have blinkers left and right so that the only thing that they are able to see is code - their own code. They code like mad and create this island miracle peace of functionality. While doing this the missed the 4 meetings and the 15 mails that defined standards. They miss the patterns and do code that can never be reused or maintained. Software development is team play. If you want to be a genius loner - develop a new string theory to explain the earth – but stay out of software development.

To determine death - a body comes handy

We are all afraid of death.

But software developers are even more afraid of exceptions being thrown. But in the situation where I need to find a problem nothing is more valuable than being able to see the error occurring.
If I have the smoking gun I’m not far from the gangster. Don’t just click away errors but look at what they say. If you don’t read the exception details no one will. Don’t just delete rows that should not be in the database – analyze them together with the business logic that should prevented them from getting in there in the first place. If you have a process using up all memory, only aboard the guy if you have no other choice. There are tons of tools that you can use to find out what is going on inside the process at the moment.
If you have a body that’s the first step to find out why the guy is dead.

Mark the right testicle

Have you heard from the guy that got the wrong testicle removed in hospital because they did not mark the right one.

Same in software development: If you find a problem in another person’s code. Try to describe the problem as accurate as possible. Not the usual crap that I need to hear every day: “there is something wrong in you code - I guess - because I got an exception – but I can’t remember exactly what I did”.

Dude - you are potential marking the wrong testicle. The other person might fix something that was not broken and leave something broken that you were not able to document correctly. You caused two problems.

Ok tell the guy everything you can get: Parameters, Exception Type, and method you called and stack-trace - the more the better.