How to keep your IT staff ?

Some time ago I came across very nice article about “why IT people change their work”. Mostly I agreed with everything I read there, but there are few things I would like to add.

Today, more then ever, trying to retain employees in the IT became very difficult task. I hope decision-makers will read this article and draw some conclusions.

Here is my list of most important things IT guys expect from their companies. Give them that and they will stay in your company longer. Close your eye on some of them and say goodbye to your IT engineers…

1. Money – at the end of the day, we all work for money. Engineers are geeks, but they also have families they need to support. When I say money, I mean competitive salary + bonus. Bonus stimulates people to work hard and it gives them a feeling that a company appreciates their hard work. If they are doing a good job they are enabling your company to make money, so share the wealth.

2. 40 hour work weeks – there are always times when you will need to have staff available beyond the normal 40 hour work week but if it is consistent, you have a project management problem and possibly an employee morale problem. IT comes with enough stress by default. If stress level is high and longer then 40 hours per week, even biggest workaholics will crack.

3. Flexible work schedules – there is no need for IT people to be in the office all the time. With broadband access available almost anywhere, there is no reason not to give some “work from home” time (as long as their performance warrants it).

4. Overtime – make sure you compensate this either with money or time off. Worst thing is to do neither! If you ignore the fact that your employees burn themselves out, you are working against your company on a long term.

5. Listen to your employees – if an employee gives a relevant input on a project and he is being ignored, then you might as well be telling them that they suck! Speak with your employees about everything and be transparent! Employees want to know what is happening in the company whether it is good or bad. Guessing is the worst thing. If you don’t speak with your employees they will start guessing. Employees might guess you are about to fire them, or sell a company, or something third, and will leave. Nobody wants to stay on a sinking ship, if they guess the ship is sinking. So, give them real input and be honest. IT guys are also humans, they appreciate a little honesty.

6. Perform annual reviews on time – this means on or before their anniversary date. Nothing makes an employee feel devalued more than wondering what management thinks of their performance (and not getting a raise).

7. Use modern IT processes – this doesn’t necessarily mean an agile methodology but a process for IT projects that doesn’t suck the life out of people by putting too much red tape in place. Try to make a progress in your organization by staying on-the-edge with development tools and methodologies.

8. Provide company sponsored “outside” activities – employees love to be given time outside of work with the team to blow off steam. This can be as simple as playing tennis or bowling or just a visit to a beer garden.

9. Good hardware – don’t be cheap! Give your employees the latest and greatest when it comes to computer hardware. It makes the work more enjoyable to be using latest machines and it just might make them a bit more productive.

10. Cross training – don’t create silos in your work environment. Nothing will demotivate employees more than doing the same thing every single day. Let people move around a bit in the projects. If you have your project management done correctly, this should be pretty easy to do. This also is a huge advantage to your organization if you start to have turn-over. Spend some money on external training for your employees – conferences and courses. Give some budget to every employee and let him decide on which external training to spend it.

These 10 points listed cost some money. But it is nothing compared to the damage you have when your highly skilled employee with lots of internal know-how leaves the company.

The bottom line here is that if you don’t show, with action, that you value your employees they are going to become unhappy at some point and leave (even the good ones). Your employees keep your business running so if they are not happy you have nothing to make your customers happy as well.

Book reviews…

Somehow I was lucky that last couple of months stress level was on minimum so I decided to use it until new stress tsunami comes. No, I didn’t ride horses nor played golf nor went out to cheat on my wife nor other tempting things. Instead, I read books, geek books. Actually there were couple of books standing on my to-do-list-before-I-get-kids. Here is a short review of each.

jcip
1. Java Concurrency in Practice by Brian Goetz
Just simple – astonishing! I was amazed how low my knowledge of concurrency is. With new multi-core processors showing up every day, concurrency issues are becoming extremely important. Somehow I was always thinking that JVM will take care of that. I still think that low level concurrency issues should be handled by JVM. We have to think about concurrent users executing our code, but code executing on underlying processor forest should be handled by JVM. On the contrary, JVM specification clearly states: “if some code can be distributed on more processors, JVM will do it without taking care of synchronization issues. Developers need to care about synchronizing their code”. This can lead to some very weird execution path of non-atomic operations like for example increment operation. Variable increment is actually consisted of 3 steps – read variable, increment, write back. Two threads in some unlucky timing can get completely different values of incrementation. Brian’s explanations are in plain and simple language easily understandable to everyone.
Highly recommended to ALL Java developers!

esb

2. Enterprise Service Bus by David Chappell
Very good introduction into ESB world. If you are a beginner in this area, this is a must book for you. Explanations are very clear and it gives good guide lines where to go in case you are faced with enterprise architecture and integration issues. Even tough David works for Sonic company, which has its own proprietary ESB solution, he didn’t market it. I liked that. He stayed independent and gave a glance of concepts and technologies, without going into any specific solution.
Recommended to IT Architects.

peaa

3. Patterns of Enterprise Application Architecture by Martin Fowler
Huh, hard to tell. Mixed feelings. We all know who is Martin Fowler and he wrote all of his valuable experience inhere. But it was written in 2003.
Unfortunately for Martin, most of chapters in his book are deprecated. He dedicated more then 100 pages to ORM patterns which I am sure nobody uses now because you have tools for that. He also mentions heavily EJB 2.0 and how to avoid known problems with it. In 2003 this was for sure very valuable. Nevertheless I read the whole book, from cover to cover. Martin is a great expert and every word from him is highly appreciable.
I can’t really recommend it anymore.

Well, stress level is still on acceptable level so I am continuing with my geek books. There are only 3 more great books to go – “Beyond Software Architecture”, “Enterprise Integration Patterns” and still in printing new release of “Effective Java” by Joshua Bloch.
Mmmm… so many sleepless nights… so much knowledge… my wife will hate me so much… she will not speak with me and that will give me more time to read… mmm…

I am going to order more books.

Maven vs. Ant and deployment strategies…

I had an interesting discussion with a couple of developers from one major insurance company where I was working as an external consultant.
Discussion was about Maven usage. They have by-the-book maven development environment – Archiva maven repository, Continuum continuous build and Maven plugin for Eclipse. It all works pretty well.

Until you want to add a new library.

A guy who likes Maven comes and says: “Maven is much better then Ant, because it gives you better control over libraries”. But when it comes to adding a new library, then he spends half an hour configuring Archiva, Continuum, calling other colleague to help him with deployment etc.

There is another guy who dislikes Maven because he cannot convert web project to Eclipse WTP so he could debug in Tomcat instead of deploying everything to WebSphere. But he said he found a tool in Google Code called m2wtp which you can use exactly for this purpose.

Hmm, I am not an expert on Maven, but what is wrong with using plain old Ant?
There are so many tools/frameworks today that we developers need to learn, last thing we want to waste our time on is with build tool. And they did waste quite a lot of time in deploying just one jar file. Even if you master that and include new library in Maven quite quickly, I see another bigger problem. Often in projects I like to experiment with different libraries to try to find a tool that best fit my needs. If I have to deploy every test library to Maven repository just to be able to see how it works and then remove it again, I am sure I would eventually end up in a mental hospital. Plus, I don’t want everybody else to see how I experiment with different libraries. With Maven, they see it.

I am an old fashioned Ant fan and quite frankly I don’t see anything wrong with that. My machine is my space. I can include what ever I want and play around with it. When I see that code works fine, I can send it to SVN repository. One of my preferred working environments is like this:
local machine -> test server -> preproduction server -> production server.
Every developer works on his local machine and plays with the code. Tester checks out code from SVN and deploys it to test server where testing team does their part. Integrator deploys code from test server to preproduction server where final functional/performance/integration tests are performed. If all is well, we go live.

For me this is all the control in the world that we need. Controlling jars (what Maven is doing) is just a small and first step that is actually hurting developers because it influences their everyday work.

Again, I must say that I am not Maven expert and maybe all these things can be done differently. I just wrote what I saw in that company which has quite a large IT department and I guess people who know how to configure Maven. Even then, build should be easy and straightforward process not blocker and time waster. There are other places were we should waste our time and loose our hair.