Technical Debt - III

I promised to offer three ways to limit technical debt – Personally, how to impact members on the team you contribute on, and how to impact members on the team you manage. I would like to start with the first. Please be aware: This is not a guide to managing your manager, but how to avoid sticking yourself in the victim role. This is about how to do good work that you are proud of, so you can take responsibility for it.

As Steve Poling pointed out in the previous comments - sometimes you have to take on debt to stay afloat. You need to ship the product today to bring in the revenue; some of that revenue can be used to pay off the technical debt. I don't mean to stick you in a binary thought pattern - the question of technical debt is not yes or no but "how much."

These posts are just about techniques to use to keep you in control of your process, instead of becoming it's victim.

Let's start by analyzing a conversation that is happening, right now, all over the world:

Manager: "We need the foo feature by Friday."
Do-er: "I need two weeks."
Manager: "We need it Friday."
Do-er: "To do it right would take two weeks."
Manager: "Look, it doesn't have to be great. Just Done."
Do-er: "Well, I guess I could just hack in a conditional ..."
Manager: "Can you have that done by Friday?"
Do-er: "I guess. If I work in the evenings a little."
Manager: "GREAT! Do It."

Before we re-write this conversation, a little applied psychology here: By backing down and "finding a way", the contributor is training his manager to ask for unreasonable things. Think about it. The manager asks for more than what is possible, the contributor puts up a faux fight ... then yields. (Worse, the contributor is saying that his first estimate should not be trusted.)

Next time the manager needs something done "real quick now", who on the team is he going to go to? And what is he going to expect?

Also, notice that the quality shortcut is implicit. The contributor never says "In order to hit the date, I will short quality. I will add in a hard-to-understand, hard-to-test feature that will be undocumented and hard to maintain. I will increase the cost of all future development on this module by about two percent."

Instead, he said "Ok, boss", then maybe went home and kicked his dog. We don't know, but the cycle of miscommunication that starts with the boss (what does "gotta have it" mean, anyway?) has been continued.

As an industry, we have to stop doing this. We have to grow up.

Let's try this again:

Manager: "We need the foo feature by Friday."
Do-er: "I can have it done the following Friday – Oct 14"
Manager: "We need it Friday."
Do-er: "As it stands, given our departmental quality standards, I don’t know how to do what you are asking. I can, however, present a few options."
Manager: "Go on."
Do-er: "We could assign Sarah to write the frobble sub-feature. Joe could do the system and integration tests, so I could write the code. We could skip our quality standards, or we could ship on October 14"
Manager: "Sarah is busy doing XXY. Joe is busy doing ABC. We need that code on Friday!"
Do-er: "Ok. Send me an email approving the quality slip, and I'll do it."
Manager: "um ... what?"
Do-er: "I can hit the date if I take certain risks. If you approve and take responsibility for the risk, I can do it; I just need an email."
Manager: "What happens if it doesn't work?"
Do-er: "Well, you took responsibility for it and approved the risk. I'd say it's about 10% that we have a minor bug, 20% that it’s a show-stopper."
Manager: "There can be no show-stoppers!"
Do-er: "Ok. We could assign Joe to do the system and integration tests ..."

You see where this is going. The contributor is offering real options to management to make explicit tradeoffs. The manager, of course, doesn’t WANT to make those tradeoffs, and doesn't want to take responsibility for those tradeoffs – but we're not letting him off the hook. (Yes, I'm tough on managers here. Don't worry, I will be tough on contributors later.)

Is this confrontational? Yes ... a little. The key is to present three to five very valid options for manager. That's not a confrontation; it's asking the boss to be boss, to make the big decision.

Now, consider: If anything was less important, you could find someone else to help out. Thus, if everyone else in the department is working on something else and can't be spared, this functionality needed on Friday is actually the least important thing the team is working on! Also Consider: If we back down at this point, we sacrifice our life, make a compromise that is a violation of our professional standards, and incent management to continue the practice.

Finally, consider: Assuming you are competent and this is work on a legacy system, there really is no one else who can learn this. If the boss fires you tomorrow (he won't) and assigns someone else, it will take them two weeks to even figure out what the software is doing. He would be a fool to remove us. Unless annual review season is this very week, we have nothing to fear, and even then, we're talking about losing a percent or two off our raise; three at most.

In order to vastly decrease technical debt at the personal level, all we have to do is grow a spine. Of course, that is simple, not easy. And when it is a hack that will keep the cash flowing and prevent layoffs, it may just need to happen. (Hint: Those don't really happen that often.)

The example above got into some pretty ridiculous circles at the end. Sometimes, a manager or executive will not 'play fair', and will try to get the circles to continue until you give up, frustrated and tired. They may use coercion, power, or the threat of power.

By framing our shortcuts as choices with explicit compromises, we can show the true cost of cutting quality, and, six times out of ten, the result will be a choice with less technical debt. Maybe not none, but less.

The example above was contrived, so I will end with a real conversation from last week:

Project Manager: "Will we have the bar function today?"
Me: "No."
PM: "But ... we need it today!"
Me: "It doesn’t even have customer signoff. I couldn’t release it if I wanted to."
PM: "We promised bar TODAY!"
Me: "Was Johanna, our customer acceptance tester, in the room for that commitment?"
PM: "No."
Me: "Was I?" (I honestly did not remember; you could tell by my tone of voice)
PM: "No."
Me: "Was the engineering team lead?"
PM: "No."
Me: "Well, then, think of it this way. When the full-time analyst and the full-time developer for the bar function left, Johanna and I took over, in addition to our other full-time responsibilities, and we are going to deliver bar two or three days late. I don’t think that is a problem. I think it is something to celebrate!"

And I walked away quickly.

Sometimes, the way to be most effective in your job is to act as if you don't care about it.