Change does not roll in on the wheels of inevitability, but comes through continuous struggle.
-Martin Luther King, Jr.
Dr. King was right – change is not easy – it’s a continual struggle. Creating software, almost by definition, is change. So, to start with, we need to understand that creating software means that we are the agents of change and thus the instigators of a continual struggle. This struggle is the cost of making the world, or our little corner of it, better in some way.
Why is change a struggle? Because it makes people uncomfortable. Why does it make people uncomfortable? Because it asks us to change our habits. Habits take a lot of time to develop and are costly to create (time is, in fact, money). And whether we know it or not we value our habits greatly – whether it’s stopping for our morning latte, or coding on our favorite IDE.
So let’s take a break right at this point. The first really important thing to realize is that by asking folks to change, we are asking them to discard valuable habits and replace them with new ones. That is, we are asking for something valuable from another person. We might as well be asking them to hand over a sizable amount of money (the amount of money in this analogy might vary depending on just how important or deeply ingrained the particular habit is). So thinking about this – would we lightly ask someone to put a significant amount of money on the table, regardless our expectation of a high return?
So if we can get our head around the idea that change is asking people to put something valuable on the table then we are ready to look at how dealing with the effects of change so powerfully determines our ability to create incredible software…
I think we’ve probably gotten used to it – everything related to technology changes extremely rapidly at this point. And it’s only getting faster. In software, new tools, libraries, frameworks, and even programming languages pop up and then quickly become mainstream. While how aggressive a particular team is at keeping up with the latest trends varies widely, even the slowest adopters couldn’t be called slow by objective standards. In order to take advantage of new efficiencies and avoid having their stack become obsolete and unsupportable – teams adopt new/different technologies pretty rapidly, these days.
So, no matter how change-averse you are – I would argue that if you’re making software, you probably are still dealing with a fair amount of change on a regular basis. The questions is really – are you dealing with it well – or are you letting it suck the life out of your development team?
A team that is handling change well may still be uncomfortable with change at times – but will be hungry for it, excited about it, and invigorated by it.
A team that is not handling change well will probably have something of a knee-jerk reaction of fear and dread when the idea of potential change is discussed.
So think about the last time your team decided to implement a new practice such as pair programming or test driven development. Or when a tooling change was made – perhaps using a new version control system or a new type of server platform. What was the general reaction like? Did the team rally – did it flounder?
As you can probably gather by this point – this particular “people concern” affects every part of software in a big way. It is “More Important Than Code” in a lot of ways and it is definitely a tool that we all need to have in our software tool belts!
To that end, part 2 of this post will continue by explaining not only how to deal with change but how, with practice, it can be used to multiply our ability to create incredible software.