The Dopefly Tech Blog

<< The Dopefly Tech Blog Main page

Technical Debt - How to fix it when you're not allowed to

posted under category: Software Quality on April 9, 2011 at 1:00 am by MrNate

I have been talking about my friend, who was in a technical-debt-pickle when he called me. Something else he mentioned over the phone was that the owners of his giant application were not keen on paying for anything but features. It's not surprising.

In an agile project, work is done in sprints 1-3 weeks in length. Teams set goals for features they can accomplish in that time. When application customers hear about a refactoring sprint, it goes over like a lead balloon. "You want to work for 2 weeks and not add features?" Like Oracle and open source, they just don't get it.

So what do you do when you can't get a budget for fixing the last decade of technical debt build-up?

I gave him my best advice, and some of my points leaned toward subverting the wishes of uninformed management and customers. Without putting your job in jeopardy, I think this is something you have to do sometimes. But how do you do it? How do you pay down some of the technical debt principal when managers say no?

First, you need to have the technical debt conversation with the customers & owners. Help them realize that by allowing this debt to live on, they are perpetrating higher interest payments in IT man hours. No sane management group would deny you the time you need, however, I know that a lot of companies are run by the most insane people.

Shot down or passed over from there, you have to pad estimates. You have been estimating high anyways because of those technical debt interest payments where it takes half of your time trying not to break other modules, finding the right files to copy and paste, or trying to remember how to use the terrible API left by some former employee. Pad higher and take that extra time to fix some of the bigger problems.

I find that, when I get myself fully in to a program, where I can feel it breathe, I start to dream about it. It's is a good thing. All my best system thinking tends to happen while I'm reading a book. Offline, I discover the pattern and identify new objects that will help me jump that next hurdle. At work the next day, I merely have to type what I envisioned.

Refactoring doesn't take a lot of time, it takes better thinking. A little padding and some daydreams will get you there.

You may be able to add this padding to each release cycle, agile or not. Call it unit testing. Call it the software release time, call it the cycle preparation time, call it quality insurance. No reason to lie about it being there. Also, no reason to share the gritty details of what's being done.

With limited refactoring time, it's ok if a refactor project is stalled halfway through. When I leave one and pick it up again, I find that I have newer, better ideas.

Going back to the people you report to, I would point out my review of my friend Terrence Ryan's book Driving Technical Change, which really seems to fit the bill here.

The final way to subvert the authority for the betterment of all, and goes along with the golden rule of technical debt (keep it visible!), is to bring it up, often. It's easy to ignore a dog waiting patiently by the door, but when it keeps yapping, you'll want to let it out. It's easy to say no to some engineers who want to run an expensive project, but if they just won't shut up about it, it becomes easier to say yes. Once, my team begged the CEO of our small software company to rewrite an app. Then we begged some more. Then we begged some more. We pointed out problems, we started to shout it from the cube-top, and eventually, he gave in. It works.

I don't think this list is exhaustive by any means. Does anyone want to share their experience or ideas?

Too old to comment!
On Apr 9, 2011 at 1:00 AM Peter Boughton (dopefly_blog, by way of said:
Not sure the repeated begging works for everyone - will depend on the characters involved?

Definitely agree with constantly bringing it up as a reason for increasingly inflated times, longer testing, and so on.

Probably also helps to be precise about what can be done to solve it "if I spend X hours/days on Y system/process, I can remove Z% of the debt from that area". Not always easy to do, but *if you can* accurately quantify it - and show a clear improvement for further work on that section - they should be more inclined to listen to and trust you for next time you say you want to fix something.
(Of course, the flip side, you need to be *certain* it'll noticably improve things, otherwise they'll think you were just wasting time, and will be even harder to convince.)

Oh and...
>> Refactoring doesn't take a lot of time, it takes better thinking. A little padding and some daydreams will get you there.

Absolutely! Sometimes a developer's best work is when they're not moving, just staring abstractly into space.

(And a pity when others misunderstand, taking that for not doing anything and a perfect opportunity to interrupt.)

On Apr 9, 2011 at 1:00 AM Nathan Strutz ( said:
Great comments, Peter. Thanks!

On Apr 11, 2011 at 1:00 AM Phillip Senn ( said:
I think you've got to look at it from your bosses perspective too though.

If you've ever hired someone, it really gives you a different outlook on things.

On Apr 11, 2011 at 1:00 AM Nathan Strutz ( said:

I know, you have a good point there. The topic is pretty touchy. I hate to suggest to people that they undermine the authority of those who sign their paychecks. Honestly, I'm not sure I would even have the balls for it, most of the time. But there are those times and places where it's necessary to do it the right way. I'm just trying to encourage people to be better programmers.

My friend Dan, on the Facebook repost of this blog, mentioned his co-workers were a hair short of a mutiny. I'd like to keep us all far from there. That is not a pleasant experience for anyone involved.

On Apr 12, 2011 at 1:00 AM Yves (yves.arsenault who can't believe it's not said:
I've really been enjoying this series of articles. I've certainly worked on projects where refactoring was "barely" an option.... and the gorilla in the room kept growing.
Too old to comment!