The most difficult thing in any company is to change it’s culture. You see, companies are used to operate in certain frames of mind and they do not accept change lightly. Also, people have the tendency of sticking in comfort zone. Working in standard and set ways is nice and comfy. Why on earth would I leave this place for something big and scary? Well, for starters to improve yourself. And improvement is always good. Stagnation, bad. Improvement, good. OK?

 

About half a year ago, I stumbled on some intranet application that had “old school” HTML coding in it. I say “old school” because people think that positioning things in HTML via tables, using inline styles and FONT and BR tags is old school. It is not. It is bad manners. Sure we had to do stuff like that in the past, but I can’t remember a single reason to do it since CSS2 became a de facto standard. Anyway, I had two options. To leave thins as they are or to try and change the culture and make people to learn something new.

I decided the best thing to do this would be to have a short 101 presentation on HTML + CSS. To show people what is out there and how to use it (I can’t really believe I am saying that in 2014). What took me by surprise was the resistance I encountered.

This got me thinking. How to change the culture so that going out of the zone will not be frowned upon? To be honest, I have no clear answer for this. One way to do it is just showing people how new things will ease their process.

When I came to this gig, we were, I think about 5 out of 12 on Joel’s test. We did have source control, bug database, quiet working conditions, used best tools money could buy and candidates definitely wrote code in their interviews (at least I did). Overall not bad, considering I came from 3 out of 12 company. Anyway, the thing that bothered me most is that every time you made a change to the application you had to go through about 30 to 60 minute process, to move that application to integration and testing environment. Not to mention that the process was error prone. So, one day, I encountered BuildMaster, an automated build tool with which the same task would take about 1 minute. And all I will have to do is press a button. Groovy.

For proof of concept demo, I installed a free version of the application and ported one user heavy application to it. It really took a minute for tool to check out latest version of software from version control, build it and publish it to desired server. On top of that everything worked. I showcased the thing to co-workers. And again got mixed feelings. Some where really enthusiastic, some were less. However, when they realized that this will save them an hour a build, plus detect build issues prior deployment, people started to warm up. And today, there isn’t a single application deployed manually anymore. Hence, I managed to change the culture a tiny bit.

In case you care, we are now 7 out of 12 on the test as we can also build and deploy application in one step and do nightly and daily automated builds. Well, actually, we are 6 out of 12, because we no longer have quiet working conditions. But that is a story that should be told entirely on it’s own.