Adventures while building a Silverlight Enterprise application part #27

It's been a while again, but it's been a bit of a hectic time. I've been approached by the good people of silverlightshow.net, who have invited me to write some articles for them, but more on that later. I've also been struggling with something I've seen coming, but underestimated, fear of change. That's what today's post is about, fear of change in a software company.

The background
When I got hired at the company I've been working for, for over a year now, the main purpose was to take the current development team, which has been developing in older technology for a long time, and help them to take full advantage of the latest Microsoft technology. Back then I took some time to think about the challenges I might face. One of the things I quickly realized is that fear of change would eventually become an issue. I never imagined it to be this strong and though to overcome.

As we started discussing how the new system should look the other developers where thrilled and everything looked good, but as time progressed and team members became more aware of the changes on different levels, some team members started to revert back to old ways. At times this has been fed by non-technical colleagues, some times it is fuelled by the fact that a lot of custom code is outstanding with customers, and quite a few times this is caused by a fear of change by some of the developers themselves.

Now, this all sounds very negative on a team I'm part of myself, however I've seen it happen a lot of times and I know a lot of others are struggling with the same thing. Do you hear sentences like "We've always done it this way and it works" and "I've seen that approach fail catastrophically once" as if they are arguments to not change anything? I hear them at least once every couple of weeks.

Why is fear of change a problem?
One might argue that this is not a problem. Just do your job and that's that. As long as the software you build fulfills the users needs, you're a winner, right? Well, no. With the old version of the software we keep seeing issues with maintenance, deployment and running it in a web environment. This makes maintaining the software expensive and complicated and it limits us in what we can do. All the more reason to do things differently, right?
So from a business perspective not changing things will eventually cause problems. Does that mean that the old software was bad? No. The point is that the environment the software has to work in combined with the requirements that are put on it, change. This means changing the software becomes inevitable.

Take Windows for example. The kernel that was originally build for Windows NT back in the late eighties was a great peace of software engineering and it worked fine for many years providing great stability to several incarnations of the Windows OS. Only in the past couple of years, the IT landscape started changing in terms of what was expected from a kernel. More and more people started using multi-core CPU's even in their PC's and multi CPU PC's are starting to emerge in the market place more and more. So Microsoft made a decision to rewrite part of the NT kernel to better support these multi core systems in a more efficient way. Though? Sure. Scary? I'd say so. But that didn't stop them from doing it and this change is now part of Windows 7. Again a stable OS, no end-of-the-world-as-we-know-it scenario's, just another major release of Windows. Sure, it must have caused the people working on it some blood, sweat and tears, but they can look back at a great achievement.

So "we've always done it this way and it works" is not really an argument to not change anything. The fact that it works doesn't mean it can not be improved upon, adapted to new possibilities and requirements. In fact, whenever someone says this to me, it makes me want to change it even more, not for the sake of it, but because it makes it all the more evident that the team needs that change in order to move forward.

The other one, "I've seen that approach fail catastrophically once" and less drastic expressions along the same line are another expression of fear. So it failed last time you've tried it? Great, that means you have experience and you know some of the pitfalls already. All the more reason to try that approach again and succeed.

So now what?
So what am I going to do about it? Fight. This may sound simplistic, but it starts with that. I realize that every change I'd like to make to the system is possibly going to be a struggle. Some of these might even fail.
Preparation is key here. It will take a lot of thought to determine what changes might be subject to resistance and what arguments I'm going to bring to the table to convince both technical and non-technical colleagues that this change is necessary and good.
Another help in this is to get others aware that this fear of change is actually there and is a problem for moving forward. In the end any help is welcome.

That concludes this episode, which I hope helps people to better understand this problem. Another great article on this I came across is written by Alexander Johannesen and can be found here.