In a post to his site, Matthias Noback talks about code complexity and how this relates to the overall "churn" (the rate of change) in a project.

Code complexity often gets measured by calculating the Cyclomatic Complexity per unit of code. The number can be calculated by taking all the branches of the code into consideration. [...] In general, we always strive for low code complexity. Unfortunately, many projects that you'll inherit ("legacy projects"), will contain code that has high code complexity, and no tests.

[...] Code complexity doesn't always have to be a big problem. If a class has high code complexity, but you never have to touch it, there's no problem at all. [...] What's really dangerous for a project is when a class with a high code complexity often needs to be modified. Every change will be dangerous. [...] Michael Feathers introduced the word "churn" for change rate of files in a project. Churn gets its own number, just like code complexity.

He then talks about combining these two numbers to provide an even more in-depth look at your code. It can give more insight into the relationship between "difficult to change", "number of changes" and the times a file has changed in the past. He mentions "it's okay" thinking (the current state is alright but not great) and shares some of his own hypotheses, observations and advice.