An interesting look at how change affects those in development field and what level of resistance it tends to be met with once it comes about.

We’re doing some process improvements and stuff where I work to meet some compliance requirements at the moment. As part of this, we’ve been looking at ways to improve the development process. We traditionally have followed what I’d like to call a “butchered agile waterfall” method. It’s kind of a waterfall that makes it’s mind up halfway down where it’s going to fall. Part of this process is to try and get a separation between production, test and development environments, and so somehow direct the waterfall a little more. The project itself is really just like common sense with some compliance type buzzwords around it. If that’s what it takes to get it done, then so be it.

What is more interesting though, is the cross section of developers that I’m working with to bring this change in. I think I’ve uncovered a grouping of developers about change, and the types of tools and languages these developers like to use. Starting from the developers that like change the least….

COBOL developers
- Of the ones I’ve worked with, these guys have been the most resistant to change. It makes sense I guess, because if they DID like change, they’d probably be developing in a more modern language. Interestingly, the COBOL developers seem to have the oldest processes, and not much in the way of productivity tools. These guys are really REALLY difficult to win over to get process improvements happening, and in some cases, will actively fight against change. The other side of this though, is they are often REALLY focussed on the business benefit. [Read the rest]