Complexity Debt – don’t “fix it”, “keep a lid on it”

So you just discovered that your code-base has racked up a whole load of complexity debt. This  maybe explains why progress seems so painfully slow lately. You briefly think of suggesting a major complexity-reducing refactoring effort. This will delay the next release significantly, but foreshorten the time to the following releases. Plus a cleaner, simpler code-base will make the world a nicer happier place, right?

But you don’t suggest this. You’re human and self-preservation is an instinct. Precisely because of the recent slow progress, there is a lot of disapointment on the whole product delivery front at the minute. Suggesting another big delay doesn’t feel like the best career move just now.

Luckily there is another, more subtle way to get to that happier place without climbing out on long limbs over thin ice.

Don’t repay the debt in one big painful bang – just keep a lid on it. And watch it begin to disipate as though by magic.

You use personality, charisma, leadership and/or donuts to convince your team that henceforth, they will not add any more complexity debt to the code base. Now watch what happens…

If I need to add to a method with a CC of 20 (where the threshold is say 15) and I add a couple of new paths, then I temporarily increase the complexity from 20 to 22. Uh oh, I said I wouldn’t do that. No problem – I’m working on the method already, so I have a good handle on what it does. I just extract a suitable lump into a new method with a nice helpful name and bingo, I have 2 methods each within tolerance instead of 1 over. The 2 methods are simpler and easier to understand and maintain than the 1 before, and the overall code-base debt just went down a bit. Well, I feel good about this.

But wait. That one new method pushes the containing class over the class-level complexity threshold. Again, I refactor the class while its workings are in my head already (perhaps I use move field or extract class). Again, if the class was previously over-threshold, then I probably just reduced the overall debt a bit more.

The same will happen when anyone trys to add to any overly-complex package. And as the xs framework sets thresholds at every level of design breakout, the developers are relieved of the temptation to “hide” complexity by pushing it up or down the hierarchy. The code-base becomes truly less complex, without anyone really trying.

This is cool enough to be named – how about “KALOI” for “keep a lid on it”.

KALOI is supported by Structure101 and there is more explicit support in the pipeline. More on this later.

2 Comments

  1. Matisse Enzer

    I recently released a tool, “countperl” that does static code analysis of Perl files and gives you a report of all the subroutines and “main” code in all the files, sorted in decending order of complexity. You run the script, giving it the path9s) to one or more perl files and/or directories and it finds the perl files and analyzes them.
    There’s more detail at: http://twoalpha.blogspot.com/2006/12/countperl-count-lines-packages-subs-and.html

  2. Architecture warnings in Eclipse | Deconstructing Software

    […] violations. With almost no effort, the code-base will evolve towards the intended architecture (the KALOI […]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.