"When in Rome, do as the Romans do!"
This is a old saying. It was first said by St. Ambrose who was the Bishop of Milan over 1.600 years ago.
In Rome they fasted on Saturday. When the bishop of Rome visited Milan, St. Ambrose was asked why they didn't do the same in Milan (I guess a bit condemnatory). St. Ambrose then replied:
"When I am at Rome, I fast on a Saturday; when I am at Milan, I do not. Follow the custom of the Church where you are."
Later this was changed to "When in Rome, do as the Romans do". The meaning of this, in a developer context, is that you should adapt to the environment you are working in. Do as the others do.
Well, enough with word origins. The reason why I referee to this origin is that I don't think it always is a good idea to follow it.
Have you ever worked with people who uses this phrase a lot:
"We have always done it this way, so why should we do it any different now?".
It's probably the same guy who says:
"Why do we need to write unit tests and use continuous integration? It only slows down the development. Let’s just do it the old way, we are getting it done this way too."
This guy is probably right. He will get the things done, but he will use a lot more time because he will spend a fare amount of time in the debugger hunting for bugs. Probably this is the guy who creates a new solution every time the product needs to be extended, because he is afraid of breaking something. He doesn't have a safety net.
This brings me to the point of this post. If you are a consultant or a permanent employee, you should not always follow what is done in the company you work for. Maybe the way things are done, isn't the best way? You should try to change this. It's your obligation as a responsible developer. I'm not saying that you should start a revolution. You should be critical, but understanding. Try to convince your co-workers to start using continuous integration if they already aren’t doing so. Get them to start writing unit tests. I guess the best way to go about this is; Show, don't tell. If you start writing unit tests and using CI, the co-workers will see the advantages of using these techniques. After a while they also want to start using it. I'm just using unit test and CI as an example, there are lots of other ways to improve. A starting point can be one of these books: The pragmatic programmer, Code Complete or ShipIT.
If you are the one fitting the above quotes, you should cut your co-worker with the new ideas some slack. Give his ideas a shot; it may lead to something wonderful. If you’re the one with the ideas; don't give up after just one try. Talk about your ideas. Find some hard facts that support your statements. Be enthusiastic and passionate.
Tags: thoughts